SGI Developer Toolbox 6.1

home *** CD-ROM | disk | FTP | other *** search

/ SGI Developer Toolbox 6.1 / SGI Developer Toolbox 6.1 - Disc 1.iso / toolbox / FAQs / SGIfaqs / SGI-Hardware-faq < prev next >

Wrap

Text File | 1996-11-11 | 191KB | 4,871 lines

SGI Hardware Questions and Answers ================================== The following is a list of questions and answers culled from the last 1800 messages to comp.sys.sgi.hardware. Note that the first entry here is the April 6, 1994 SGI Hardware FAQ list. It is also included in the toolbox/hardware directory. Where there were multiple answers, they are shown as --- 1 --- [............] --- 2 --- [............] etc cetera. --------------------------------------------------------------------------- Table of Contents (1) - SGI Hardware FAQ (2) - Moire Patterns (3) - Disk problems on crashed system (4) - Forced Perfect Terminators (5) - Determining graphics mode (6) - Printer port gets stuck (7) - Maximum Memory capacity (8) - Disk Striping Questions (9) - Seagate ST42100N configuration (10) - SCSI Timeout problems (11) - Making a new Boot disk (12) - Accessing VAX Tape Drives from Indigo (13) - Indigo CPU/SCSI Board Problems (14) - Exabyte 8205 on an Indigo2 (15) - Disks for Indy's (16) - Indy Graphics (17) - VME Interrupts (18) - Extending Keyboard, Mouse and Video signals (19) - More SCSI for Challenge M (20) - Device Driver Guide for 4.x versus 5.x (21) - Trouble with Indigo Disk Drive (22) - Bru for floptical? (23) - Using serial port to detect a switch closure (24) - Toshiba XM3401BC on Indigo (25) - Software protection (26) - Using 'setmon' (27) - Fastest Baud rate for serial ports (28) - Odd baud rates (29) - SCSI Devices on Twin Tower machines (30) - Connecting Video Projectors to SGI platforms (31) - Using 'sysid' for software licensing (32) - Books about MIPS processors (33) - Wangtek DAT on an Indy? (34) - DAT drive on Power Series Systems (35) - Serial Port & Modem Cabling for Indigo (36) - FDDI/CDDI on Indigo2 (37) - Apple (or other) CD-ROM on SGI (38) - Connecting Tektronix color printer to SCSI port (39) - Disks for Challenge L (40) - Multichannel Option Problems (41) - Flicker on Indigo2 (42) - Fuji M2263SA on an Indy? (43) - 4D/25 Boot problem (44) - Maximum Memory on a 4D/25 (45) - Bru and M/O drives (46) - VME Transfer Problems (47) - Pio_bcopyin and pio_bcopyout arguments (48) - DMA Rates on EISA & GIO (49) - SGI Periodic Table (50) - Quick Ring for Indy? (51) - Reading audio from CD-ROM drive into aiff file (52) - Determining current video scan rate (53) - Using Vigra MMI-210 in a 4D/320S (54) - Software upgrade required for R4400? (55) - FDDI in Indigo2 (56) - 1024x768 support with Elan for projector (57) - Reading data from DAT with a program (58) - Replacement Indigo Keyboard? (59) - Can't find tape drive on 4D/35 (60) - Will 525 MB tapes work in QIC 150 drives? (61) - Second SCSI bus for Indigo? (62) - Audio programming on Indigo2 (applies to Indigo and Indy as well) (63) - Audio programming - part 2 (64) - Power Connections for SGI systems (65) - Maxtor 8760E drive on 4D/240S (66) - Panic crashes (67) - Swap space or RAM? (68) - Help with Exabyte 8505 tape drive (69) - Indy Third Party Drive Problems (70) - R2000A/R3000 - What does this mean? (71) - Heat problems with Seagate Barracuda in an R4000 Indigo? (72) - Optical Disk Drive suggestions? (73) - Moving a drive from one machine to another (74) - IO4 Bus arbitration question (75) - Disk drive problem with Indigo (76) - Print problems with LaserWriter Pro (77) - NFS performance problems on 4D/35 (78) - Indigo Environmental Operating conditions (79) - Apple CD-ROM - Part 2 [see (37)] (80) - Difference between R4000 in Indigo and R4000PC in Indy ******************************************************************************* (1) - SGI Hardware FAQ [1002 lines long] --------------------------------------------------------------------------- From: sgi-faq@viz.tamu.edu (The SGI FAQ group) Newsgroups: comp.sys.sgi.misc,comp.answers,news.answers Subject: SGI hardware Frequently Asked Questions (FAQ) Supersedes: <hardware_786697207@viz.tamu.edu> Followup-To: comp.sys.sgi.misc Date: 20 Dec 1994 06:57:15 GMT Organization: Visualization Lab, Texas A&M University Lines: 1159 Approved: news-answers-request@mit.edu Expires: 17 Jan 1995 07:00:07 GMT Message-ID: <hardware_787906807@viz.tamu.edu> Reply-To: sgi-faq@viz.tamu.edu (The SGI FAQ group) NNTP-Posting-Host: viz.tamu.edu Originator: sgi-faq@viz Archive-name: sgi/faq/hardware Last-modified: Sat Dec 17 12:14:15 CST 1994 SGI hardware Frequently Asked Questions (FAQ) This is one of the Silicon Graphics FAQ series, which consists of: SGI admin FAQ - IRIX system administration SGI apps FAQ - Applications and miscellaneous programming SGI audio FAQ - Audio applications and programming SGI graphics FAQ - Graphics and user environment customization SGI hardware FAQ - Hardware SGI impressario FAQ - IRIS Impressario SGI inventor FAQ - IRIS Inventor SGI misc FAQ - Introduction & miscellaneous information SGI movie FAQ - Movies SGI performer FAQ - IRIS Performer SGI pointer FAQ - Pointer to the other FAQs Read the misc FAQ for information about the FAQs themselves. Each FAQ is posted to comp.sys.sgi.misc and to the news.answers and comp.answers newsgroups (whose purpose is to store FAQs) twice per month. If you can't find one of the FAQs with your news program, you can get it by anonymous FTP from one of these sites: viz.tamu.edu:/pub/sgi/faq/ rtfm.mit.edu:/pub/usenet/news.answers/sgi/faq/ ftp.uu.net:/usenet/news.answers/sgi/faq/ Note that rtfm.mit.edu is home to many other FAQs and informational documents, and is a good place to look if you can't find an answer here. If you can't use FTP, send mail to mail-server@rtfm.mit.edu with the word 'help' on a line by itself in the text, and it will send you a document describing how to get files from rtfm.mit.edu by mail. Send the command 'send usenet/news.answers/sgi/faq/misc' to get the SGI misc FAQ, and similarly for the other FAQs. Finally, the FAQs are on the World Wide Web at http://www.cis.ohio-state.edu/hypertext/faq/usenet/sgi/top.html The SGI FAQs are freely distributable and we encourage wide circulation. You MUST keep the FAQs intact, including headers and this notice. The contents are accurate as far as we know, but the usual disclaimers apply. (In particular, copies of the SGI FAQs published on paper or CD-ROM are certain to be out of date!) Please send additions and changes to sgi-faq@viz.tamu.edu. Topics covered in this FAQ: --------------------------- -1- GENERAL INFORMATION -2- Where can I get a copy of SGI's Periodic Table of the Irises? -3- What third-party vendors sell thus-and-such for SGIs? -4- Where can I get used SGI machines? -5- What is my old SGI machine worth? -6- What about my IRIS 2000 or 3000? -7- Should I shut off my Iris at night? -8- How fast is my R4000 or R4400 machine? -9- What is the IP number of each SGI model? -10- MEMORY -11- Can I mix 1MB and 2MB SIMMS in my 4D/20 & 4D/25 Personal IRISes? -12- Can I add 4MB SIMMS to my 4D/20 or 4D/25 PI? -13- How many 4MB SIMMS can be put into an Indigo? -14- How can I find a bad SIMM? -15- Why does my system tell me I need a revision C Memory Controller (MC) chip? -16- MONITORS AND VIDEO HARDWARE -17- My monitor is maladjusted in some way. How to fix it? -18- Can I have 2 graphics displays on my Indigo? -19- What do I need to do stereo on an Onyx/RE2? -20- Can I use my SGI monitor on my PC? -21- Can I use my PC monitor on my SGI? -22- What video formats, scan rate, etc. do SGI monitors support? -23- How can I set my Indy to use 1280x1024 pixels on a third-party monitor? -24- STORAGE DEVICES -25- What do all these SCSI technical terms mean? -26- How many SCSI devices can I have on an Indigo? -27- How do I install external SCSI disks on my SGI? -28- What kind of DAT drive does SGI sell for the Indigo? -29- Can I use a 3rd-party cartridge tape drive on my Indigo? -30- Which Exabyte drives work with SGI systems? -31- How to connect my 3rd-party tape drive to my SGI? -32- How should I set up my tape drive so tar's 'r' and 'u' options work? -33- What do I do when I can't read a tar tape made on another system? -34- Why can't I write a tape on my DEC DAT drive and read it on my SGI? -35- How can I recover a partially overwritten tar tape? -36- When and how should I clean my tape drive? -37- How can I eject a jammed tape or CD? -38- Can I use a non-SGI CD-ROM on my SGI? -39- Why can't Joe User eject his CD-ROM? -40- How can Joe User mount and unmount his MO disk? -41- Why do SGI SCSI controllers have host ID 0 instead of the usual 7? -42- What about Syquest removable media drives? -43- EVERYTHING ELSE -44- How long can my monitor/keyboard/mouse cables be? -45- How fast is the Indigo parallel port? -46- What are the differences between the Indigo R4000 and Indigo2? -47- What high speed interfaces are available for Onyx? -48- Why doesn't my modem work? -49- What mice can I use with my Indigo or Indigo2? -50- What mice or trackballs can I use with my Onyx? -51- What about uninterruptable power supplies? ---------------------------------------------------------------------- Subject: -1- GENERAL INFORMATION Date: 09 Jan 94 00:00:01 EST The next few items discuss general questions about hardware. ------------------------------ Subject: -2- Where can I get a copy of SGI's Periodic Table of the Irises? Date: 10 Dec 93 00:00:01 EST SGI Direct (see the misc FAQ for phone numbers) and your friendly neighborhood salesbeing are guaranteed to have the latest. Nonetheless, the misc FAQ lists the locations of FTPable Postscript versions under "What are some related network-accessible documents?". ------------------------------ Subject: -3- What third-party vendors sell thus-and-such for SGIs? Date: 17 Feb 94 00:00:01 EST Look in viz.tamu.edu:/pub/sgi/lists/3rd-party for lists of third- party disks, memory, magneto-optical drives and general vendors. ------------------------------ Subject: -4- Where can I get used SGI machines? Date: 18 Feb 94 00:00:01 CST The SGI Systems Remarketing group makes used SGI machines available to sales representatives. If you want to buy a used SGI machine, ask your local sales rep or call SGI Direct (see the misc FAQ for phone numbers). wgbhres@world.std.com (Boris Levitin) lists some other remarketers: Concorde Groupe 800-437-8621, 404-423-0070 Concorde Groupe, fax 404-426-8130 Falcon Systems, Jeff Geiger 800-326-1002 Minicomputer Exchange, John McFarland 408-733-4400 R-Squared, Tony Sciacca 800-777-3478 Security Computer Sales 612-227-5683 Sun Valley Technical Repair, Joe Ferris 408-224-6261 X-Systems, Jon Nies 800-886-5343, xsys@xsys.com X-Systems, fax 303-443-7440 XS International 404-874-1212 ------------------------------ Subject: -5- What is my old SGI machine worth? Date: 26 May 93 00:00:01 CST Thanks to Thomas Sippel-Dau <cmaae47@imperial.ac.uk> for this summary: Since computer technology has been improving so rapidly, this is difficult to answer generally. But you can take the following approches to get somewhere near a realistic estimate. 1. The Book Value. This assumes the computer is an investment object which is written down over a certain time. At the end of this time it is assumed that the residual value will pay for scrapping the object, so you do not have to pay someone to take it away. About 5 years seems reasonable for computers. Value the current value Price the original price n the age of the machine in months p depreciation rate 1.6% (for 62.5 months useful life) 1.1 Linear method: Value = Price * ( 1 - n * p ) 1.2 Degressive method: Value = Price * ( 1 - 2 * p ) ** n In the first 4 years the degressive method will give lower values. Once the degressive monthly depreciation is lower than the linear one, you should sell the machine and buy a new one, otherwise you pay more tax than you need to (talk to your accountants first, they should know the exact depreciation rate and method). 2. Comparative method. Get the new price of a similar current machine. Multiply the current price by any usefulness multipliers. For example: An Indigo R3000 server costs $8000 (N.B. NOT the real price) An Iris 4D/25 is about half the speed of it Then the current value of the 4D/25 cannot be more than $4000 regardless of what the book value says. For this you must strip or enhance the machine to a current standard. Say you take the price of an Indigo with 432 disk Mbyte and 16 Mbyte memory to assess the residual value of a 4D/25 with eight Mbyte memory and 330 Mbyte hard disk. You will arrive at the price after you have upgraded the the 4D/25 to 16 Mbyte. Since both machines are not very useful (stand alone) with so little disk space, you can allow for the difference in disk space when you calculate the price of the whole running system. For this method the old system must be able to run current software usefully. A system that does not run current software has no value, but see below. You should also take account of the maintenance cost for about three years, which is when a system you buy now would be due for replacement according to the book value method. 3. Components and options. You can view the system as an assembly of useful parts, such as monitor, keyboard, disk drives, system box, electronics module. If you have extra memory or disks (over and above the currently useful minimum), you can value them at about 80% of the price you currently have to pay third party suppliers. 4. Residual use value. If you can find a dedicated use for an old general purpose machine, then this could give you a final number. However, you need to allow for any work you have to put in to get to that state, and to keep the system there. You will also find that only reasonably large organisations have such dedicated uses. Finally, a word about maintenance: If you have one system only, and you cannot afford to lose it, you need to take maintenance, regardless of how much it is. From about 5 systems you can save yourself maintenance if you can afford to lose the odd system and load its uses onto the remaining ones. But remember that rescheduling people often meets resistance, and keeping people idle because of a system failure is extremely expensive. ------------------------------ Subject: -6- What about my IRIS 2000 or 3000? Date: 27 Feb 94 00:00:01 EST Look in the misc FAQ for pointers to the IRIS 2000/3000 mailing list and FAQ (the latter under "What are some related network-accessible documents?"). ------------------------------ Subject: -7- Should I shut off my Iris at night? Date: 01 Jul 94 00:00:01 EST (Home users often ask this.) No, you should not. The hardware is designed for continuous use, and IRIX schedules cleanup tasks for the early morning. (See the cron(1M) and crontab(1) manpages and the files in /usr/spool/cron.) Disks, tapes, CD-ROMs etc. consume little power when idle and should NEVER be turned off or on (or connected or disconnected) when the system is running. However, turning off your *monitor* will save power and prolong its life. ------------------------------ Subject: -8- How fast is my R4000 or R4400 machine? Date: 30 Apr 94 00:00:01 EST Eric Williams <williams@agomoda.asd.sgi.com> reveals all: It is confusing to spec the clock frequency for the R4000 and R4400 because they are so flexible. There are four interesting numbers: - internal clock - external clock - secondary cache access cycle - SYSINT frequency Let's start by specifying the processor internal frequency. e.g. 150 MHz. All other frequencies are specified with respect to this one. For programs that get good primary cache hit rates this number will determine the performance. The clock input to the R4400 (i.e. the crystal you buy) is always half the internal frequency. In this case 75 MHz. This is generally the number used by the chip manufacturers, to specify the speed of the part. However from a system point of view, it is the least visible to the user, and therefore IMHO the least interesting. The secondary cache read and write access cycles are programmable in terms the internal clock frequency (e.g. 150 MHz cycles). This allows you to trade off the cost/speed of secondary cache rams with system performance. When upgrading from 100 MHz to 150 MHz you can either keep the same rams and increase the SCache access cycle or install faster rams and keep the number of cycles constant. The first option keeps the cost to a minimum while the second maximizes performance. Finally the interface that talks to the system (SYSINT) can run at a programmable fraction (1/2, 1/3, ...) of the internal frequency. For the example 150 MHz processor, this could be 75 MHz, 50 MHz, etc. This puts an upper limit on the bandwidth to memory and affects some latency parameters. Typically you would program the system interface to run synchronously with the memory controller. From what I've heard here about the Indy R4400 upgrade (I'm not involved with it) I think you could say the following: - the internal clock (primary cache, instruction execution, etc) increases from 100 MHz to 150 MHz - the clock crystal increases from 50 MHz to 75 MHz - the secondary cache access times stays the same in absolute terms (but increases in terms of internal clock cycles) - the system interface to memory stays at 50 MHz (100 MHz div 2, vs. 150 MHz div 3) BTW, the Indy upgrade example illustrates why IMHO the 75 MHz external frequency of the R4400 is not an interesting number to quote. Performance of real programs will be determined by the internal 150 MHz clock, the secondary cache timing and the system interface/memory speed, not the 75 MHz external clock. ------------------------------ Subject: -9- What is the IP number of each SGI model? Date: 13 May 94 00:00:01 EST There are two different IP numbers, one referring to the hardware and one to the software (kernel configuration). The latter is what you see when you type 'hinv'. Here is a table of both numbers: HW IP SW IP Model CPU Speed ----- ----- -------------------- ----- ----------- IP2 IP2 IRIS 3000 68020 IP4 IP4 4D/50, 4D/70 R2000 12.5MHz IP4.5 IP4.5 4D/80, 4D/85 R2000 16MHz 4D/60 R2300 IP5 IP5 4D/1x0 R3000 16.7MHz IP6 IP6 4D/20 R3000 12.5MHz IP10 IP6 4D/25 R3000 20MHz IP7 IP7 4D/2x0 R3000 25MHz IP9 IP9 4D/210 R3000 25MHz IP13 IP7 4D/3x0 R3000 33MHz IP15 IP7 4D/4x0 R3000 40MHz IP12 IP12 4D/30, 4D/35, Indigo R3000 30-36MHz IP17 IP17 Crimson R4x00 50 or 75MHz IP19 IP19 Onyx, Challenge R4x00 50 or 75MHz IP20 IP20 Indigo R4000 R4x00 50 or 75MHz IP22 IP22 Indigo2 R4x00 50 or 75MHz IP24 IP22 Indy R4x00 50 or 75MHz The missing numbers were used for machines that were not released. R4x00 machines can be 50 MHz R4000s or 75Mhz R4400s. 'hinv' reports twice that in recent versions of IRIX; see the previous question for an explanation. We use the smaller number here for consistency. ------------------------------ Subject: -10- MEMORY Date: 09 Jan 94 00:00:01 EST The next few items discuss adding memory. ------------------------------ Subject: -11- Can I mix 1MB and 2MB SIMMS in my 4D/20 & 4D/25 Personal IRISes? Date: 20 May 93 00:00:01 CST From PIPELINE March/April 1992, page 18: You can use either 1MB or 2MB SIMMs in these systems. If you mix 1MB and 2MB SIMMs, all sixteen memory slots must be filled. ------------------------------ Subject: -12- Can I add 4MB SIMMS to my 4D/20 or 4D/25 PI? Date: 19 Jun 94 00:00:01 EST The short answer is "maybe". Read on. Thanks to Michael Portuesi <portuesi@tweezers.esd.sgi.com> for this helpful summary: The 4D/2* has 16 memory slots. You get access to them by removeing the right plastic cover and the metal shield underneath (box seen from the front). The slots are in the upper, left corner (box now seen from the right). The slots have to be populated by SIMMs (some kind of industry standard). I think 80 or even 100ns is allright, but take a look at the speed of your own SIMMs. SIMMs should always be mounted in groups of four. In a plain 8MB 4D/20 you have eight 1MB SIMMs. They are placed in slots A and B in this figure: ABCD ABCD ABCD ABCD If you upgrade to 16MB using eight more 1MB SIMMs you simply insert the new SIMMs in slots C and D. If you are going to mix different SIMMs you should always have the the same type of SIMM in slots with the same letter. As far as I know, the SGI 32MB memory upgrade is sixteen 2MB SIMMs, and they are mounted in all the slots. Now, I have been told (but haven't tried it) that it is possible to mix 1 and 2MB SIMMs. The important point is that the 2MB SIMMs should be in the lowest numbered slots. To get 24MB you should populate the slots as shown (signatures are, 1 = 1MB SIMM, 2 = 2MB SIMM, 4 = 4MB SIMM, . = empty slot): 2211 2211 2211 2211 The good news is that you can get 4MB SIMMs from third-party vendors outpricing the 2MB SIMMs available from SGI. To get 32MB you mount 8 4MB SIMMs like this: 44.. 44.. 44.. 44.. The bad news is that you cannot mix 4MB SIMMs with 1 or 2MB SIMMs (leaving a lot of spare SIMMs) and even worse, not all 4MB SIMMs will function properly. Among the "good" SIMMs are those from Toshiba. They should look something like this (information I got from a news article posted by Chris Miller <eagle!news@ucbvax.berkeley.edu>): module ID tags: chip numbers: -------------- --------- TOSHIBA | TOSHIBA | | 9025AAA | TC514100J-80 | THM94000S-80 | | JAPAN | JAPAN 9020HDK -------------- --------- Among the "bad" SIMMs are those from Hitachi: chip numbers: JAPAN R200 9026 2NN HM514100JP8H Other memory configurations that we have tried are (0 = empty slot, 1 = 1MB SIMM, 2 = 2MB SIMM, H = 4MB Hitachi SIMM, T = 4MB Toshiba SIMM): 1100 1100 Came up as 8MB (correct) 1100 1100 1111 1111 Came up as 16MB (correct) 1111 1111 TT11 TT11 Came up as 64MB (wrong) TT11 TT11 T000 T000 Came up as 16MB (correct) T000 T000 TT00 TT00 Came up as 32MB (correct) TT00 TT00 HH00 HH00 Came up as 0MB (wrong!!) HH00 HH00 TH00 TH00 Came up as 32MB (correct) TH00 TH00 TTH0 TTH0 Came up as 48MB (correct) TTH0 TTH0 TTHH TTHH Came up as 64MB (correct) TTHH TTHH 11TT 11TT Comes up as 16MB 11TT 11TT It appears as though the machine checks the first bank of chips (port 0) to determine the chip size and assumes that the rest are the same. The Hitachi 4MB SIMMs are NOT correctly detected. It is important that the 4MB SIMMs in slot A are 'good'. Then you are free to use "bad" 4MB SIMMs in the rest of the slots (this is my experience), and it is possible to upgrade to 64 MB populating all the slots with 4MB SIMMs. When you do the actual seating of the SIMMs you should take precautions (wear a static strap, work on a static pad) not to damage the memory. Sometimes you will have to reseat a module. If a SIMM is not properly seated it will probably show up on the diagnostics terminal (if you have one attached) during power on. After a succesful power on you should enter the PROM monitor and issue the 'hinv' command. This should tell you how much memory you have (or how much the 4D/2* believes it has). If this is correct you are ready to boot. Dave Olson <olson@sgi.com> adds: [The "good" vs. "bad" SIMM business] is a PROM bug. We had a fix, but that PROM never released. We didn't have 4 MB SIMMs when the last shipped prom released. We read a memory location with the 4M SIMMs before we initialzed it. SIMMs that power up all 1's work; those that power up all 0's require a reset or two (by then the memory was initialized). The Toshiba simms worked once; I've heard that current 4M Toshiba simms may not. The moral of the story: many people do fine with 4M SIMMs in their 4D25s, but don't buy them without a money-back guarantee. ------------------------------ Subject: -13- How many 4MB SIMMS can be put into an Indigo? Date: 20 May 93 00:00:01 CST One (1) set. Says Dave Olson <olson@sgi.com>: Due to a design flaw, only one set of 4MB SIMMs (16 MB per bank) can be used in an R3000 Indigo, 4D/30 and 4D/35. This limitation doesn't apply to the 2 MB or 8 MB SIMMs. ------------------------------ Subject: -14- How can I find a bad SIMM? Date: 20 Feb 94 00:00:01 EST Articles in the Mar/Apr 92 and May/Jun 93 Pipelines describe how to find bad SIMMs in Personal Irises. The PROM diagnostics on Indigos and newer can find them for you. ------------------------------ Subject: -15- Why does my system tell me I need a revision C Memory Controller (MC) chip? Date: 30 Apr 94 00:00:01 EST Dave Olson <olson@sgi.com> explains: Long, long story. Short synopsis: if you don't get memory errors, don't worry about it. Slightly longer: A number of vendors' 16 Mbit chips had a bug in them. We found it, and they agreed it was their bug, but they were looking at a long, long DRAM spin time, so we worked around it in a new rev (rev C) of the memory controller. The symptom was primarily parity errors; this could be confused with the other parity error problem we have, thus the warning message in 5.2. At least some of the vendors that had the problem should have fixed DRAM shipping by now, which is not to say that SIMMs you buy now have the new DRAMs on them. Not all vendors had the problem. ------------------------------ Subject: -16- MONITORS AND VIDEO HARDWARE Date: 09 Jan 94 00:00:01 EST The next few items discuss monitors and video hardware. ------------------------------ Subject: -17- My monitor is maladjusted in some way. How to fix it? Date: 27 Feb 94 00:00:01 EST Get these handy writeups on monitor adjustment: viz.tamu.edu:/pub/sgi/hardware/adjusting-your-monitor viz.tamu.edu:/pub/sgi/hardware/adjusting-your-monitor-II ------------------------------ Subject: -18- Can I have 2 graphics displays on my Indigo? Date: 18 Feb 94 00:00:01 CST The Dual Headed IRIS Indigo with Entry Graphics (W-RPC-DH) sounds like what you want. It has two Entry Graphics subsystems and two 16" monitors. Contact SGI Direct (see the misc FAQ for phone numbers) for more information. Starting with Irix release 5.1.1.2, there is also support for dual-head configurations on Indigo-2's. Both heterogeneous (Extreme-XL) and homogeneous (XL-XL) hardware combinations are possible. ------------------------------ Subject: -19- What do I need to do stereo on an Onyx/RE2? Date: 14 Jun 93 Paul Spencer <spencer@hailwood.asd.sgi.com> illuminates us with: You just need the shutter glasses (and the emitter, which comes with the glasses). This is available as a kit from SGI. The standard SGI RealityEngine monitor can do stereo; you don't need a special CRT. Demo programs and sample source code are part of every IRIX release. ------------------------------ Subject: -20- Can I use my SGI monitor on my PC? Date: 24 Aug 94 00:00:01 EST Rick McLeod <mcleod@esprit.esd.sgi.com> writes: This depends on the SGI monitor. PCs want multifrequency/ multiscanning/multisyncing monitors. Earlier SGI platforms supplied fixed frequency or dual scan mode monitors. These will not work on PCs. Some current SGI machines (Indy, Indigo2, Onyx) ship with multiscan monitors. These will most likely work with a PC, but make sure that the monitor gets the proper sync signal. Clinton Keith <clint@art.ray.com> adds his implementation details: The GDM-17E11 works on my PC with a Diamond Speedstar 24x. I used a VGA connector that brought out the RGB V and H sync lines from the 24X into BNC connectors (commonly avaliable at a local computer store). I connected the V sync H sync and Green lines together and connected this line and the Red and Blue lines to a BNC-to-DB13W3 connector (bought a workstation supply vendor) which went to the monitor. I then set up the 24X to provide -/- sync voltages and selected the highest vertical and horizontal scan rates I available. Unfortunately, the monitor refused to display 640x480 (pride?) but did well at 800x600, 1024x768 and 1280x1024. There was a slight greenish tint to the black areas of the screen. It seems as though connecting the sync lines to the Green may have added a DC bias, but the effect is minor. ------------------------------ Subject: -21- Can I use my PC monitor on my SGI? Date: 28 Jan 94 00:00:01 EST Rick McLeod <mcleod@esprit.esd.sgi.com> writes: The PC monitor must be able to handle a 1024x768 non-interlaced signal to be used with Indigo starter graphics or Indy. Most of SGI systems operate at 1280x1024 non-interlaced. Most PC monitors will not be able to deal with the scan rates required to display a stereo image. ------------------------------ Subject: -22- What video formats, scan rate, etc. do SGI monitors support? Date: 20 Feb 94 00:00:01 EST It depends on the monitor. See the Sep/Oct 93 Pipeline (and a correction on p. 26 of the Nov/Dec 93 Pipeline) for a tabulation of the characteristics of most types of SGI monitors. ------------------------------ Subject: -23- How can I set my Indy to use 1280x1024 pixels on a third -party monitor? Date: 19 May 94 00:00:01 EST As root, do 'nvram monitor h' and reboot. See 'man 2 sgikopt' for details. ------------------------------ Subject: -24- STORAGE DEVICES Date: 09 Jan 94 00:00:01 EST The next few items discuss storage devices. Tapes, mostly. ------------------------------ Subject: -25- What do all these SCSI technical terms mean? Date: 12 Feb 94 00:00:01 EST Look in rtfm.mit.edu:/pub/usenet/comp.periphs.scsi/ for the comp.periphs.scsi FAQ. ------------------------------ Subject: -26- How many SCSI devices can I have on an Indigo? Date: 26 May 93 00:00:01 CST You can have 7 SCSI devices, and as long as you have clean cabling, and one (and only one!) SCSI terminator at the end of the chain, and keep total cable length under 6 meters, there should be no problems, as far as the Indigo's bus itself goes. On an Indigo2, you can have 7 devices on the external SCSI bus, and up to 3 devices on the internal bus. ------------------------------ Subject: -27- How do I install external SCSI disks on my SGI? Date: 02 Feb 94 00:00:01 CST The basic procedure is to use 'fx' to format and label the drive (the label contains the partition layout), use 'mkfs' to create the empty filesystem, create the mount points and put the proper entries into /etc/fstab. The IRIX Site Administrator's Guide describes this in detail. The graphical Disk and File tool assumes you bought your drive from SGI, in which case the 'fx' and 'mkfs' parts have already been done. It also assumes you want to use the entire drive as a single partition. ------------------------------ Subject: -28- What kind of DAT drive does SGI sell for the Indigo? Date: 26 May 93 00:00:01 CST The Indigo DAT drive is an ArDAT Python 4320. The drive SGI sells is completely standard 3.5" form factor hardware (no compression), but has firmware that so far ARDAT is selling only to SGI to provide audio over SCSI support, and to fix some bugs. ------------------------------ Subject: -29- Can I use a 3rd-party cartridge tape drive on my Indigo? Date: 26 May 93 00:00:01 CST The Tandberg and Archive QIC24 and QIC-150 drives both work just fine on the Indigo (both come in external versions), as do the Wangtek and Tandberg QIC-1000 drives (as of this quarter, and 4.0.5F or later). ------------------------------ Subject: -30- Which Exabyte drives work with SGI systems? Date: 26 May 93 00:00:01 CST Dave Olson <olson@sgi.com> says: First, the 8200 (2.3 Gb). The original version we qualified was 100% stock from Exabyte. It had some problems on the ESD machines at power on, because of the somewhat non-standard way it handled the send-diag SCSI command. The current rev (252T) we ship is also standard firmware from Exabyte (to the best of my knowledge), and fixes that problem, and is also more robust in the face of servo problems. The 8500 (5 Gb) isn't fully qualified (by SGI) yet, and there is some argument over whether we will ask for custom firmware; I think we are definitely slanting towards standard firmware. The gotcha here is that Exabyte has released so many firmware revs for the 8500, that the word 'standard' is somewhat of a joke. I've lost touch with that effort a bit, so I don't know what firmware rev we are currently working with. 4.0.1 is the first IRIX release with support for the 8500, earlier releases will work to varying degrees with different 8500 firmware. ------------------------------ Subject: -31- How to connect my 3rd-party tape drive to my SGI? Date: 08 Oct 94 00:00:01 CST Only part of the voluminous literature on the topic may be found at viz.tamu.edu:/pub/sgi/hardware/3rd-party-DAT-drive viz.tamu.edu:/pub/sgi/hardware/exabyte-8505-setup viz.tamu.edu:/pub/sgi/hardware/exabyte-howto-for-sgis ------------------------------ Subject: -32- How should I set up my tape drive so tar's 'r' and 'u' options work? Date: 09 Jan 94 00:00:01 EST Sara Kunz <kunz@binah.cc.brandeis.edu> writes: Use the variable block size tape devices. These are called /dev/rmt/tps0d#nsv and /dev/rmt/tps0d#nrnsv, where '#' is the tape's SCSI device number. If the tape drive is properly attached (it should appear in 'hinv's listing), saying '/dev/MAKEDEV tps' should create the devices for you. If the tape drive in question is the tape drive with the lowest SCSI ID, '/dev/MAKEDEV tapelinks' will link the appropriate devices to /dev/tape and /dev/nrtape. Note that appending is physically possible only on 9-track and DAT tapes. ------------------------------ Subject: -33- What do I do when I can't read a tar tape made on another system? Date: 04 May 94 00:00:01 EST Glenn Randers-Pehrson <glennrp@BRL.MIL> says: You may be trying to read a non-byte-swapped tape on a byte-swapped device, or vice versa. Tar tapes written on SGI's QIC cartridge drive, using the default device, /dev/tape, are in byte-swapped format. Sun tapes are usually not byte-swapped. On the IRIS, you can read non-byte-swapped tapes with tar -xvf /dev/tapens and you can write non-byte-swapped tapes destined for a Sun with tar -cvf /dev/tapens [directory_or_filename[s]] On the SUN, you can read byte-swapped tapes with dd if=/dev/rmt0 conv=swab | tar -xvf - Read the tar(1) (DIAGNOSTICS section) and tps(7M) manpages for the gory details. DAT tapes may have an additional problem: SGI DATs have a default blocking factor of 512 and HP DATs have a maximum blocking factor of 128. You can either rewrite your tape on the SGI with tar cvbf 20 /dev/tape files and read it on the HP (or whatever) with tar xvbf 20 /dev/tape or you can use 'dd' to translate like so, dd if=/dev/tape ibs=512b of=- obs=20b | tar xvf - where '512' is whatever blocking factor you used to write the tape. ------------------------------ Subject: -34- Why can't I write a tape on my DEC DAT drive and read it on my SGI? Date: 03 Dec 94 00:00:01 EST DEC DAT drives use hardware compression by default, and SGI DAT drives can't handle that. Turn it off. Furthermore, some SGI DAT drives hang when trying to read a hardware- compressed tape, instead of saying "incompatible media" as they should. This is fixed in recent firmware; call the TAC to get an upgrade. ------------------------------ Subject: -35- How can I recover a partially overwritten tar tape? Date: 10 Dec 93 00:00:01 EST People often overwrite the beginning of large tar archive, leaving the first bit of the tape overwritten and the rest presumably intact. This is usually NOT recoverable. However, if you're feeling lucky, you might (says Dave Olson <olson@sgi.com>) try something like 'mt fsf 4; mt bsf 2; tar xe' or 'mt fsf 4; mt bsr 2; tar xe'. You might also try 'tar cv foo', where 'foo' is slightly bigger than what you overwrote the archive with the first time, and pull the plug on the tape drive before it writes the EOF. Then power it back up and try 'tar xe'. If this sounds unlikely to work, you're right. Don't let it happen; use the write protect tab. ------------------------------ Subject: -36- When and how should I clean my tape drive? Date: 20 Feb 94 00:00:01 EST 9-track and QIC drives should be cleaned every 8 hours of use, or more often when using many new tapes, and certainly when the number of "recoverable errors" gets uncomfortably high. See the Nov/Dec 91 Pipeline or the "IRIS Software Installation Guide" for a detailed cleaning procedure. Briefly, shut the drive down and swab the head with isopropanol and a lintless cloth. 8mm and DAT drives need to be cleaned every 30 hours of use, using a commercial cleaning tape according to the instructions. ------------------------------ Subject: -37- How can I eject a jammed tape or CD? Date: 05 May 94 00:00:01 EST Shut down your system nicely, hold down the drive's eject button and turn the drive's power (or, for internal drives, the system's power) off and on. See also viz.tamu.edu:/pub/sgi/hardware/ejecting-jammed-tape. ------------------------------ Subject: -38- Can I use a non-SGI CD-ROM on my SGI? Date: 14 Feb 94 00:00:01 EST 4D20, 25, 70, 80 and 85s and most Power Series machines can boot only from SGI CD-ROMs. Older machines can boot only from a local tape drive or over the network. Newer machines (4D30 and 35s, Indigos, Challenges, Onyxes, Indys, etc.) have smarter PROMs and can boot from at least some third-party CD-ROMs, for example the Sony and Toshiba drives intended for Suns. The rest of this entry discusses what qualifies a drive for 4D30s and later. Dave Olson <olson@sgi.com> of SGI says, The basic requirement for Indigos is that the drive be set to use a 512 byte block size. Since Indigos don't reset the SCSI bus on reboot or halt, you *might* be able to boot your machine in some other way, set the CD-ROM's blocksize with a devscsi program while the system is up and then install from it, but I won't swear to it. Late R4K Indigos, Indys, Indigo2s, and Onyx/Challenges all know how to set the block size if the drive identifies itself as a CD-ROM, reports the block size as something other than 512 bytes in the block descriptor and accepts the new block size in the block descriptor. Rob Silvers <rsilvers@nynexst.com> reports that he has been sucessfully using a third-party dealer's Toshiba TXM3401E1 on an Indigo. It cost about $760. It is physically larger than an external Apple or Next drive. It is double speed and handles multi-session photo-CDs. 'cdromd', 'inst' and 'cdman' work, but he has not tried to boot from it as of 12 June 93. Bart Richards of Thunderstone Software <bart@thunderstone.com> writes, The following minor surgery makes a run of the mill Toshiba 3401[B|E] CDROM drive SGI [Indigo] or Sun-compatible. I got it straight from an anonymous Toshiba Tech. guy, and it worked for me. There are two solder pads located on the circuit board at the back right corner of the drive's aluminum housing when viewed from the top with the SCSI connector facing away from you. These may or may not be labeled as '0' & '1', but '0' is on the left and '1' is on the right (or closest to the edge of the circuit board). The normal state for these solder pads from the factory is for both of them to be closed. With an Exacto Knife or soldering iron (whichever is appropriate for the desired configuration), cut or solder these pads to match the entries in the following table: +++___++++++++__ |power SCSI | '0' '1' O=CUT/OPEN S=SHORTED/SOLDERED | 01| ---------- |----------------| S S Toshiba Default (2048 byte block) | | S O 512 byte blocks | TOP | O S SGI ( Bootable ) | OF | O O Sun / Integraph | DRIVE | | | | | | | |________________| DOOR ------------------------------ Subject: -39- Why can't Joe User eject his CD-ROM? Date: 24 Feb 94 00:00:01 EST - /usr/sbin/eject has the wrong permissions in IRIX 4.0.5H and IOP. It should be setuid root. Say 'chmod 4755 /usr/sbin/eject' (as root) to fix it. - Someone may be cd'ed into the CDROM directory. Do 'fuser /CDROM' to find the number(s) of the process(es) that are cd'ed there, and kill them. ------------------------------ Subject: -40- How can Joe User mount and unmount his MO disk? Date: 22 Jan 94 00:00:01 EST cdromd (mediad in IRIX 5.x) doesn't understand MO disks. You need the 'mountmo' program, at viz.tamu.edu:/pub/sgi/hardware/mountmo.c. ------------------------------ Subject: -41- Why do SGI SCSI controllers have host ID 0 instead of the usual 7? Date: 24 Feb 94 00:00:01 EST It's a controller chip default. It was left alone because it doesn't matter much: host ID doesn't affect throughput, except perhaps on a horrendously overloaded bus. However, drives whose ID is set by jumpers are usually shipped with ID 7 (all three jumpers on), so you can just plug one in to an ID 0 host. ------------------------------ Subject: -42- What about Syquest removable media drives? Date: 08 Oct 94 00:00:01 EST SGI's Bob Miller <kbob@sgi.com> has written an FAQ on using Syquest drives with SGIs. A copy is at viz.tamu.edu:/pub/sgi/hardware/syquest-on-sgi-faq. ------------------------------ Subject: -43- EVERYTHING ELSE Date: 09 Jan 94 00:00:01 EST The rest of the FAQ discusses things that didn't fit into categories. ------------------------------ Subject: -44- How long can my monitor/keyboard/mouse cables be? Date: 25 Feb 94 00:00:01 EST Dave Olson <olson@sgi.com> writes, SGI has (or had at one time) a 75 foot monitor cable on the price list. With a decent cable, this is about as far as you can get without getting pretty fuzzy; I've heard that with an extremely high quality cable, you can get to about 100 feet. Your limits may vary. EIA 423 should have no problems with up to 100 feet either, since the mouse is at 4800 baud, and the keyboard at 600. Will McCown <will@rhythm.com> adds, We routinely extend the SGI video cables up to about 150' using high- quality (Canare LV-61s) coaxial cables. For newer SGIs which use the 13W3 "D" connector instead of BNCs, adapters are available from several sources including NuData (908) 842-5757 part number 6647. The "PS/2 compatible" keyboards and mice used on the Indigo II, Indy, etc. do not accept simple extension cords as well as the older keyboard/mice. We have successfully extended these keyboards & mice up to about 100', but beyond 150' they never work. The problem lies in the high-impedance TTL-level signaling used. Beyond this distance you can use an extender box made by Cybex (205) 430-4000, which is designed to extend the IBM PS/2 keyboard and mouse. Our method for making keyboard/mouse extensions is to buy 6' IBM PS/2 keyboard extension cables (male 6-pin mini-din one end, female 6-pin mini-din on the other), and cut the connectors off of these cables leaving about a 6-12" pigtail on each connector. We then attach RJ-12 connectors (IDC type modular phone connectors) to the free end of each pigtail. We then extend the cable using flat 6-conductor phone cable, RJ-12 connectors, and "barrel" adapters. This may sound like a lot of work but it is very quick to assemble, and requires no soldering. For really long runs, Rick McLeod <mcleod@esprit.esd.sgi.com> says, Two companies provide long distance (up to a couple of thousand feet) fiber optics extensions for keyboard, mouse and monitor: Lightwave Communications (203) 878-9838 Meret Optical Communications (310) 828-7496 ------------------------------ Subject: -45- How fast is the Indigo parallel port? Date: 26 May 93 00:00:01 CST Default rate is about 200 Kbytes/sec. This can be bumped up to at least 400, and perhaps higher by changing the strobe length, assuming the other side can handshake fast enough. See the plp(7) manpage. ------------------------------ Subject: -46- What are the differences between the Indigo R4000 and Indigo2? Date: 09 Jun 93 00:00:01 EST Jamie Riotto <jamie@origami.esd.sgi.com> writes: An Indigo R4000 has two daughter board expansions which use our GIO-32BIS bus design. These cards are about the size of an index card. An Indigo2 has a 4-slot backplane design. All four slots have EISA connectors so you can have a graphics-less server with four EISA cards. Three of the slots have GIO-64 bus connectors, BUT ONLY TWO CONNECTORS CAN BE USED SIMULTANEOUSLY!. Graphics board sets take up one logical GIO-64 connection, but can take up more physical slots. The current Extreme graphics takes up one logical GIO-64 connection, but uses three slots. That means the other slot can be used for either EISA or GIO-64 expansion. Note that since not all slots have both EISA and GIO-64 connectors, you might have to shift the Extreme graphics board set up or down a slot if you want to use the fourth slot with GIO-64 expansion. GIO-64 by the way is similar to GIO-32 but is twice as wide, uses a different DMA protocol (pipelined), and used EISA form factor (with the connector moved of course :-). ------------------------------ Subject: -47- What high speed interfaces are available for Onyx? Date: 11 Jun 93 00:00:01 EST Robert van Liere <robertl@cwi.nl> writes: SGI have FDDI boards for the Onyx. These boards perform quite well although the Indigo FDDI broad preforms slightly better. I'm not sure about SGI ATM, although I guess all vendors are preparing for it. FORE systems make ATM boards for the GIO bus. Maybe they have something for the HIO as well. FORE systems, Inc 1000 Gamma Drive Pittsburgh, PA 15238-2940 412-967-4040 Fax 412-967-4044 info@fore.com GIA-100/125A (100 Mbps GIO Bus) GIA-100/175A (140 Mbps GIO Bus) and Yechezkal-Shimon Gutfreund <sgutfreund@gte.com> adds: Fore Systems, Pittsburgh PA, selles a 150Mbit/s ATM adapter card that you can use to connect to their ATM switch (using multi-mode fiber). ------------------------------ Subject: -48- Why doesn't my modem work? Date: 19 Nov 94 00:00:01 EST Lots of reasons, but here are some of the most popular: - You're not using hardware flow control. To do so, you MUST 1) use the ttyf* devices, not ttyd* or ttym*, and 2) use a "hardware handshake" 7-wire cable, which you can buy from SGI but usually *not* from a Macintosh house. Look at the serial(7) manpage for details. - The modem is configured funny. Look at the configuration scripts in /usr/lib/uucp/fix-* and see if there's one for your modem. - /usr/lib/uucp/Permissions is wrong. /usr/lib/uucp/genperm will generate Permissions entries for all /usr/lib/uucp/Systems entries. - IRIX 5.2 had several problems with serial I/O, flow control and PPP interoperability. They are fixed in patch 151. Call the TAC. ------------------------------ Subject: -49- What mice can I use with my Indigo or Indigo2? Date: 09 Jan 94 00:00:01 EST Indigos need special Indigo mice. Replacement mechanical or optical (take note, mechanical mice haters!) mice are available from SGI or directly from Mouse Systems (510-656-1117). Indigo2s can use PS/2 mice as per the pcmouse(7) manpage. Dave Yost expands on this: The Indigo2 takes any industry standard mouse of the variety variously known as "IBM PS/2", "Mouse Port" or "6-pin". A PC serial mouse won't do, even with an adaptor, unless it is claimed to work on a PS/2 through an adaptor. The Logitech "MouseMan Cordless" mouse works for me. ------------------------------ Subject: -50- What mice or trackballs can I use with my Onyx? Date: 01 Jul 94 00:00:01 EST John Kraft <jfk@lycidas.engr.sgi.com> writes: Unlike the Indigo and Indy (see above), Onyxes use a custom serial mouse. If you'd prefer an optical mouse over the standard mechanical mouse shipped with the system, call Mouse Systems (510-656-1117) or Qualix (415-572-0200). If you'd like a trackball, call Mouse-Trak (800-533-4822, email yvonne@mousetrak.com). ------------------------------ Subject: -51- What about uninterruptable power supplies? Date: 08 Oct 94 00:00:01 EST Get the UPS FAQ from navigator.jpl.nasa.gov:/pub/doc/faq/. See also viz.tamu.edu:/pub/sgi/hardware/surge-protectors. ------------------------------ End of sgi/faq/hardware Digest ****************************** -- The SGI FAQ group sgi-faq@viz.tamu.edu Finger us for info on the SGI FAQs, or look in viz.tamu.edu:/pub/sgi. (2) - Moire Patterns --------------------------------------------------------------------------- What causes those distracting moire patterns that can be seen on some monitors? I've been asked if the monitor or the computer can be adjusted to remove them. Sometimes degaussing (as in "hit the built-in degauss button) works for us. (3) - Disk problems on crashed system --------------------------------------------------------------------------- We have an R4000 Indigo that crashed pretty hard last night. When I rebooted it, it came up with the message: No volume header on device: scsi()disk(1)rdisk()partition(1)/osloader.exe Autoboot failed I called user support, and they told me to re-install eoe1.sw.unix, which I did. After doing that, upon reboot, I got the error message : Unable to load bootfile: no such device So I went into fx and did label/create/bootinfo to see if that would work. And when I rebooted this time, I got the original error message again. Somebody has been playing with your nvram settings. Try stopping at the PROM monitor, and give the command: resetenv then reset your netaddr to the correct IP address with: setenv netaddr www.xxx.yyy.zzz then try booting. (4) - Forced Perfect Terminators --------------------------------------------------------------------------- I remember some discussion quite a while ago about the different types of active terminators. My question concerns the Forced Perfect Terminators, are they better or worse than "plain" active terminators? Are there any terminators that I should avoid? The problem with FTP is that it can (in some circumstances) pull more than the allowed 4 ma per signal. This can do bad things to some SCSI controller chips. Some people have had success with it, but in general it doesn't seem to help more than active termination. Given that it violates the specs, I try to discourage people from using FPT. (5) - Determining graphics mode --------------------------------------------------------------------------- | I have just found an incompatibility between GL running on a 4D/210 running | 4.0.5C, and an Indigo R4000 Elan running 4.0.5H. The getgconfig function | does not exist on the older version. TAC says they cannot help and by the | end of the year there *may* be a fix. It is a new function, so of course won't be in older releases. Seems unlikely to be 'fixed', since it isn't a bug. | I wonder | | 1. Can I force the newer GL onto the older machine? No. | 2. Is there a solution I can demand to have now (we have full support on | both machines) ? No. | 3. Is there a good workaround - I want to know whether I am in colormap or | RGB mode and getgconfig seems to be the only way to tell me that ? I'm pretty sure there is a much older method, although I don't remember what it was, one of the graphics folks will hopefully post it. Yes. Try getdisplaymode(); FUNCTION RETURN VALUE The returned value for this function tells you which display mode is currently active. ______________________________________________ |Symbolic Name | Display Mode | |_____________________________________________| |DMSINGLE color map single buffer mode | |DMDOUBLE color map double buffer mode | |DMRGB RGB single buffer mode | |DMRGBDOUBLE RGB double buffer mode | |_____________________________________________| (6) - Printer port gets stuck --------------------------------------------------------------------------- Has anyone experienced the printer port of a 4D/35 getting stuck for no apparent reason? Zapping the daemons doesn't get it running, but a reboot (not a power cycle) does work. --- 1 --- Sounds like the cable to the printer might be long enough to cause problems, in that case. It should be no more than 2.5 meters; some printers are more sensitive than others. Using a print buffer box has helped some folks who just had to have longer cables (keep it short on the SGI side). --- 2 --- I used to have problems with my 4D/35 when the printer would jam (a frequent occurance with certain color printers). The attached program (when run as root or suid root) will clear the port. It works for me, but don't blame me if it explodes your CPU, erases your disk and destroys your printer :) -- cut here -- #include <sys/types.h> #include <fcntl.h> #include <sys/plp.h> main() { int fd; int retval; setuid(0); retval = system("/usr/lib/lpshut"); if(retval != 0) { perror("error from lpshut command"); } printf("Killing off processes using parallel port\n"); retval = system("/etc/fuser -k /dev/plp"); if(retval != 0) { perror("error from fuser command"); } if((fd = open("/dev/plp",O_RDWR)) < 0) { perror("unable to open parallel port"); exit(-1); } /* reset the printer */ retval = ioctl(fd,PLPIOCRESET); printf("Printer port reset\n"); /* start up the spooler again */ system("/usr/lib/lpsched"); printf("Printer scheduler restarted\n"); } -- cut again -- Yes, toggling the reset line on the parallel port (which is what this does) may help after things get stuck, but powercycling the printer will do the same thing. In any case, that can be a drag for long print jobs, and only treats the symptom, not the cause. (7) - Maximum Memory capacity --------------------------------------------------------------------------- >You can install 1, 2, or 3 banks of SIMMs. Each can be 4, 8, 16, 32, or 64 >MB with current DRAM sizes (the latter 2 require 16 Mb chips). >Max memory is therefore 384 MB (more than 256 will be ignored until >5.1 and later). Min memory is 16 MB. I'm sorry but this still isn't clear to me... Okay, the minimum is (1) bank of (4) 4MB SIMMs whichs equals 16MB, yes? So, would not the maximum thus be (3) banks of (4) 64MB SIMMs which equals 768MB? But this value is 2x the 384MB maximum you state. Also, do the 16MB SIMMs exceed the 18-piece chip count you cautioned us about in a previous posting? Or maybe I'm just off today on all this. There aren't enough address lines for that, so 512 is the theoretical max the system can support (yes, 512, not 384). Besides, I had a typo (I got carried away!). 32 MB per SIMM is the max (no more than 18 DRAMs per SIMM, due to capacitive loading issues). Sorry. In *theory*, the system could have 512 MB with 64Mbit chips and 64 MB per SIMM, but it will be quite a while before we know if that will really work. The 16 and 32 MB SIMMs are 16 Mbit chips; using 4 Mbit chips would be too much of a load. (8) - Disk Striping Questions --------------------------------------------------------------------------- I have a few questions about striping disks on an SGI Challenge. Is there any documentation on how to optimize a striped disk, such as how to calculate the correct step size for the lvtab, the best buffer size for reading/writing to the stripe, the use of direct i/o with a stripe, etc? There really is no such thing as an optimal stripe. It depends on just what you want to do, so you need to experiment. Does anyone have any experience with using direct i/o for writing to a striped disk and if so what if any performace gain was seen? There is some gain, since the advantage of direct i/o is direct dma to/from the user program, rather than going through the buffer cache and copying the data. Are there any good benchmarks for determining max throughput to/from a striped disk? Not really. There are a number of i/o benchmarks, but they all have their flaws (including those we use internally). Your own apps are really the best benchmark. (9) - Seagate ST42100N configuration --------------------------------------------------------------------------- I'm probably going to have to contact the vendor, but I'm hoping someone will have an answer for me over the weekend.... I bought a drive tray & 4 Seagate 5.25" 2.1GB SCSI drives (model ST42100N) for my 4d/340, but the remote SCSI ID switches on the tray aren't connected to the drives. Can someone tell me how to connect them, or failing that, just describe the pinout for the model ST42100N SCSI ID connector pins? Looking at the rear & bottom of the Seagate drive: SCSI ID etc. ------------ ------------------------- -------- |::::::::::| | SCSI data connector | |power | ------------ ------------------------- -------- | | ------ exploded view ---- | 2 4 6 8 A C E G I K (total of 10 pairs of pins) 1 3 5 7 9 B D F H J - pins 1 & 2 are currently jumpered - pins D & E are currently jumpered I'm fairly sure the last 6 pins set the SCSI ID, since the remote SCSI ID switches are 6-pin connecters, but the various combinations I've tried have come to naught so far. Actually, the "6-pin" remote SCSI ID connectors are a pair of 3-pin connectors, so there's more than a few possible combinations. And I haven't tried any of the first 14 pins yet. ;-( --- 1 --- According to my ST41200N docs (I havn't opened up my machine to check) there are 8 (eight) pin pairs to the left of the SCSI connector. Numbered left to right, starting with 1 (one), pairs 3, 4 and 5 control the SCSI ID of the unit. Pair 5 is the low bit. --- 2 --- My ST42100N drives have 10 pin pairs to the left of the SCSI connector. The drive ID pins ended up being the 3rd, 4th, and 5th pin pairs, counting from the left side of the drive, when viewing from the rear, which seems to match what Bill is saying above (Thanks Bill!!). Regardless, I'd have spent days trying to figure it out if I hadn't received a specsheet via email. Once again, Usenet beats a call to technical support hands down!! ;-) Thanks loads to Ryan J Snodgrass <rsai+@andrew.cmu.edu> for his speedy reply with the following: ST-42100N Wren 9 FH SCSI-2 Fast Z Synchronous Spindles option DC 3 Power 3 UMMMMMMMMMMMMMMMMMMMMMMMMMMMMM8 /DDDDDDDDD\ MMMMMMMMPMWMAMMMMMMMMM5:SCSI:Cable:::::::::::::::::1FM5 0 0 0 0 FMM ZD? ZDAD? TMMMMMMMMMMMMMMMMMMMMMMMMMMMMM> @D5DGDGD12Y 3o3o o o o o o o3o+o3 ZDDDDDD1 ZDDDDDD1 ZDDDDDD1 EoEo o o o o o o3o-o3 @DDDDDDY @DDDDDDY @DDDDDDY @1Y 4 2 1 @DDDY Terminator SIPS 3 3 DDBDD 3 3 3 3 3 3 3 3 @D Motor Start Delay (16 secs * ID) 3 3 3 3 @DDD Parity check enable 3 3 3 @DDDDD Motor Start option enable 3 3 @DDDDDDDDD Drive ID's, ID 0 (none) if only SCSI device 3 @DDDDDDDDDDDDD Terminator power to the Bus (vertical) @DDDDDDDDDDDDDDE Terminator power from Drive, default (vertical) 3 Terminator power from Bus (lower horizontal) LED ZDDD? (Viewed from front of drive) Z GND 3 0 3 3 MMMMOMMMOMMMMMMMMMMMMMPMWMAMMMMMMMMMMMMMMMMMMMMMMMMMMXMMMMMMMMMMMM o o o J6 pin-1 (+5v) ----o o o 3 3 3 Remote LED connection DDY 3 3 Write Protect Remote EDDDY 3 Switch cable connection 3 3 Factory Use Only DDDDDDY ST-42100N WREN 9 FH UNFORMATTED CAPACITY (MB) ________________2,200 FORMATTED CAPACITY (xx SECTORS) (MB) _____1,900* AVERAGE SECTORS PER TRACK (with spares)___96 ACTUATOR TYPE ____________________________STRAIGHT ARM TRACKS ___________________________________38,595 CYLINDERS ________________________________2,573 (user) HEADS ____________________________________15 DISCS (5.25 inch) ________________________8 MEDIA TYPE _______________________________THIN FILM RECORDING METHOD _________________________ZBR RLL (1,7) INTERNAL TRANSFER RATE (mbits/sec) _______20 to 31 EXTERNAL TRANSFER RATE (Mbytes/sec) ______10.0 Sync. SPINDLE SPEED (RPM) ______________________3,600 AVERAGE LATENCY (mSEC) ___________________8.33 BUFFER ___________________________________256 Kbyte Read Look-Ahead, Adaptive, Multi-Segmented Cache INTERFACE ________________________________SCSI-2 Fast BYTES PER TRACK __________________________57,200 avg. SECTORS PER DRIVE ________________________3,705,120 TPI (TRACKS PER INCH) ____________________2,150 BPI (BITS PER INCH) ______________________ AVERAGE ACCESS (ms) ______________________12.95 SINGLE TRACK SEEK (ms) ___________________2 MAX FULL SEEK (ms) _______________________29 MTBF (power-on hours) ____________________150,000 POWER REQUIREMENTS: +12V START-UP (amps) _4.5 +12V TYPICAL (amps) __1.5 +5V START-UP (amps) __0.8 +5V TYPICAL (amps) ___0.6 TYPICAL (watts) ______21 MAXIMUM (watts) ______58 LANDING ZONE (cyl) _______________________AUTO PARK IBM AT DRIVE TYPE ________________________0 or NONE * 512 bytes per sector, one spare sector per track, two spare cylinders per unit. Already low-level formatted at the factory. --- 3 --- Did you mean to say "ST41200N"? I'm looking at the ST42100N INSTALLATION MANUAL sheet, and it shows ten (10) jumper pairs, but as you said, the 3rd, 4th and 5th pairs starting from the left determine the SCSI ID, with the 5th pair being the LSB. Also, the 4th pair from the right, which the poster indicated was set on his drive, is the "enable parity reporting" jumper, which we also have set. (10) - SCSI Timeout problems --------------------------------------------------------------------------- >> The problem I have is that after a few transfers, the following >>message appears in the console window: > >>dks0d1s0 (/): retrying request >>sc0,1,0: cmd=0x2A timeout after 30 sec. Resetting SCSI bus. >>[particulars: Indigo1, 405F, Integral SCSI ctrl Version WD33C93B, revision D] --- 1 --- There are several things that could be at fault. I am presuming that you are using Single Ended SCSI. First and foremost is that your SCSI cable lengthis too long. This is common enough that you should really examine the length. Besides the external cables you're using between your devices, remember the lengths of the cable inside your peripheral boxes. The Max length on a SCSI bus is supposed to be about 18 feet, but the machine takes up some of that length electronically. I was told (by the SGI support line) that the Challenge M, for example uses up 6 feet itself, so you would expect to have 12 feet at your disposal. In practice, it's more like 9 or 10 feet you can safely use before running into problems. Try to reduce your cable length in whatever way possible. We were successful in getting one expansion box that holds 6 5-1/4" disks and an Exabyte drive connected to an Indigo to work where 3 expansion boxes for the disks and the box for the Exabyte drive, when connected, would cause SCSI timeouts like you mentioned. Secondly, It would appear that there was a problem with *some* of the D revision SCSI chips that Wangtek supplied to SGI. The problem would appear (for us, at least) after you hooked up a second external device to the machine. It was probably some sort of cable-length threshold that caused the problems. Before you start calling SGI for a replacement, Do yourself a favor and make sure your cabling is ok, and make sure you use SGI's terminators. Personally, I now use Differential SCSI wherever possible. --- 2 --- | There are several things that could be at fault. I am presuming that | you are using Single Ended SCSI. Yes, they are. | First and foremost is that your SCSI cable lengthis too long. This is | common enough that you should really examine the length. Besides the | external cables you're using between your devices, remember the | lengths of the cable inside your peripheral boxes. The Max length on | a SCSI bus is supposed to be about 18 feet, but the machine takes up | some of that length electronically. I was told (by the SGI support | line) that the Challenge M, for example uses up 6 feet itself, so you | would expect to have 12 feet at your disposal. In practice, it's more | like 9 or 10 feet you can safely use before running into problems. Nope. Either they misunderstood you as to which machine, or gave you just plain bad info. Challenge M is an Indigo2, and has about 15-20 cm's of internal 'cabling' (really, just PC board traces). The rest of what you say is correct though. | Secondly, It would appear that there was a problem with *some* of the | D revision SCSI chips that Wangtek supplied to SGI. The problem would | appear (for us, at least) after you hooked up a second external device | to the machine. It was probably some sort of cable-length threshold | that caused the problems. Not WangTek, Western Digital. The problem is that the chip will see (some of the chips, not all of them) transitions at 2 volts on the scsi bus, rather than 2.85. Rev D chips were not used in Indigo, just Indigo2, and some prototype Indy's. Production Indy's are using rev C chips, since they were affected by this due to different system design. Rev E 33C93B's have this problem fixed, and they will be cutin as they become available (on Indy). Rev D had some improvements for better noise immunity to rev C, but those have not been seen to be terribly noticeable. The chip is a surface mount part, so changing it would be a board swap. there are *NO* plans to do any board swaps, as no systems (other than Indy) with rev D parts have been shown to have problems with properly cabled and terminated. | Personally, I now use Differential SCSI wherever possible. The problem is that there are a very large number of SCSI devices not available in differential scsi, and single ended to differential SCSI adapters can introduce problems of their own. Certainly differential scsi has significant advantages for cable length and noise immunity, particularly at fast SCSI rates. (11) - Making a new Boot disk --------------------------------------------------------------------------- I would like to copy the contents of a boot disk (with / and /usr partitions) to another, larger disk. I used fx to format the second disk as a "boot" disk, mounted the / and /usr on the second disk, copied all the files from the original disk, tried to boot with the new one, and the system complains that it can't find the bootfile (I didn't expect it to be that easy, but it was worth a shot). So, is their an easy way to do this or do I have to do it the painful way? cd /stand; dvhtool -v c sash sash -v l /dev/rdsk/dks#d#vh Some systems also have ide and/or symmon in the volhdr, depending on system type. dvhtool -v l lists the contents in the volhdr on the root drive; specify the drive to list other drives. (12) - Accessing VAX Tape Drives from Indigo --------------------------------------------------------------------------- I have been attempting to determine what can be done about the following problem (I have been speaking with a tech support person at TGV, Inc., the manufacturer of Multinet, which is the best TCP/IP and NFS software available for VAX/VMS): >> >> You'll have to talk to SGI. Last I heard from them was about a month >> >>before 4.0.5 was released. Their tape driver/rmt server would not >> >>return any indication an EOF was incountered with fsr or fsf. >> >>I was told this would be fixed, but not for 4.0.5. >> >> >> >> As I mentioned I know bsr,fsr doesn't return any indication >> >>when an EOF in encountered. This makes doing VMS tape operations >> >>impossible. Note that this problem only exists with IRIX 4.0.5 and earlier. No other implementation of Un*x exhibits this behavior. Does anyone have any idea when this problem will be fixed? Or, if this is a zero priority item for SGI, is there a possible fix of some sort available? The particular configuration consists of a VAX running VMS V6.0, Multinet V3.2A (I have been told to upgrade to V3.2B, which might help a little bit), and Iris Indigo running IRIX 4.0.5 (I have also been told to upgrade to 4.0.5f -- will this help?). Thanks for any suggestions -- it would be good not to have to be completely redundant and purchase additional tape drives just for the Indigo. BTW, what I am attempting to do is access the tape drives on the VAX from the Indigo. ----- 1 ------ Then the problem listed above is completely irrelevant, since you aren't using the Indigo tape driver at all, and presumably that means you didn't quite explain the situation right to the folks at Multinet. The problem he refers to was fixed sometime before the 4.0.5 Indigo Patch was released. At least, his test case passed. Again, that was with the tape drive *on the SGI system*. (13) - Indigo CPU/SCSI Board Problems --------------------------------------------------------------------------- Twice now in the space of 2 days our Indigo has died. The first time the SGI technician replaced the cpu board, but didn't find any obvious cause, and now it's happened again. Symptoms are messages on pressing the reset button: sc0,1,0:cmd=0x25 timeout after 2sec. Resetting SCSI bus sc0,2,0:cmd=0x25 timeout after 2sec. Resetting SCSI bus etc and now sc0,1,0:cmd=0x28 timeout after 10sec. Resetting SCSI bus sc0,2,0:cmd=0x12 timeout after 5sec. Resetting SCSI bus etc with the external and 2nd internal drive removed, and external termination replaced. System is R4K-XS24Z, 10 months old, 48M ram, internal SGI 500M hard disk, internal Parity Micropolis 2112 1G hard disk, external HP magneto-optic disk with Ten-X Optical Conversion Unit. The magneto-optical unit has been working for 9 months. The Micropolis 2112 has been working 2 weeks, during which time we changed buildings, so the system has been switched off quite a bit. (Yes, we did check the cables, reseat the boards etc. when we saw that it was a SCSI problem.) In both cases, the problem occured when re-configuring the Xinet Appletalk server, which involved in one case re-configuring the kernel, which then apparently crashed and corrupted the "free block count" on the root partition. It is difficult to understand how a hardware problem could have been produced by these software problems, but the Indigo made a soft 'brrp' sound when it crashed the first time, but then got to the final stage of rebooting, after auto fsck'ing the disks reporting: "NAME=/tmp/atinitA1601 [EMPTY] removed" and then in the final stages, just before the login screen should appear. "IRIX killed due to bus error" Resetting once more, it again reached the final stage of rebooting before the cpu made a soft click (shudder), and then died i.e. refused to read the SCSI bus, giving the timeout errors. The SGI guy will not be happy having to drive 60 miles to replace the cpu board again, and still not knowing what could be the cause. He could only say that a recent SGI technical note advised using active terminators in the case of SCSI problems. (We already looked at the cable - it is short and of good quality). But could a 'simple' termination problem blow something on the cpu board ? --- 1 --- | Twice now in the space of 2 days our Indigo has died. | The first time the SGI technician replaced the cpu board, but | didn't find any obvious cause, and now it's happened again. | | Symptoms are messages on pressing the reset button: | sc0,1,0:cmd=0x25 timeout after 2sec. Resetting SCSI bus | sc0,2,0:cmd=0x25 timeout after 2sec. Resetting SCSI bus | etc | and now | sc0,1,0:cmd=0x28 timeout after 10sec. Resetting SCSI bus | sc0,2,0:cmd=0x12 timeout after 5sec. Resetting SCSI bus | etc | with the external and 2nd internal drive removed, and external | termination replaced. | | System is R4K-XS24Z, 10 months old, 48M ram, internal SGI | 500M hard disk, internal Parity Micropolis 2112 1G hard disk, | external HP magneto-optic disk with Ten-X Optical Conversion | Unit. The magneto-optical unit has been working for 9 months. | The Micropolis 2112 has been working 2 weeks, during which | time we changed buildings, so the system has been switched | off quite a bit. (Yes, we did check the cables, reseat the boards | etc. when we saw that it was a SCSI problem.) Take out the micropolis; and see if that fixes things. Same for the external device. Double check that you don't have extra termination. Make sure the external scsi cable is high quality. Use active termination. Make sure no pins got bent anywhere, or cables badly kinked during the move. I strongly doubt it is the cpu board or the backplane. | "IRIX killed due to bus error" Could be SCSI related. Could also be many other things, including s/w problems. If it happened just after installing s/w that has kernel parts, I would very strongly suspect that s/w, and delete it and go back to the old kernel, to find out (you did save a copy of the old kernel, right ;) ?) | Resetting once more, it again reached the final stage of rebooting | before the cpu made a soft click (shudder), and then died i.e. refused | to read the SCSI bus, giving the timeout errors. | | The SGI guy will not be happy having to drive 60 miles to replace | the cpu board again, and still not knowing what could be the cause. | He could only say that a recent SGI technical note advised using | active terminators in the case of SCSI problems. (We already | looked at the cable - it is short and of good quality). But could | a 'simple' termination problem blow something on the cpu board ? Again, I strongly doubt you have a cpu board problem. --- 2 --- >Again, I strongly doubt you have a cpu board problem. Yes, I find it hard to believe too. But we did take out the extra disks and put back the original SGI terminator, power cycled etc., but still had the SCSI timeout - even with all disks removed. We did keep a copy of the old kernel, but since the beast can't find the SCSI drives, its not much use. Yet replacing the cpu board immediately cured it - for two days, after which we had the exact same problem. Our own technician opened up the magneto-optic drive, and grumbled that it had internal termination, but it has been working happily for 9 months, with or without external termination (it is the only external device). OK, maybe the (new) second internal drive finally broke the SCSI camel's back, but ... Again, can a 'simple' termination problem blow something on the cpu board ? The SGI guy will be back this pm, but he seems as puzzled as I am. I fear he is going to tell us it 'must be' the third party drives, and that we can't use them. --- 3 --- >|But could a 'simple' termination problem blow something on the >|cpu board ? Well the sequel is that something to do with SCSI was blown on both cpu boards. On replacing the second, the SGI engineer asked me not to connect the external magneto-optic drive, and I've had no more problems for a week. But this external mo-drive has been working perfectly for 9 months, the SGI guy could not suggest what might be wrong with it, how we could test it, or even what precisely was blown on the cpu boards, and what might cause it - apparently they are shipped back to SGI and the local engineer never gets to hear what the problem with them was. We really need that mo-drive. The only things we did before the problems were to move buildings and add a second internal drive, (Micropolis 2112) which seems to work fine. --- 4 --- | Well the sequel is that something to do with SCSI was blown on both | cpu boards. On replacing the second, the SGI engineer asked me not | to connect the external magneto-optic drive, and I've had no more | problems for a week. There simply isn't anything that I know of that can blow. The termpower is protected by a PTF device, rather than a fuse, and that is on the backplane rather than the CPU board. There are also some EMI filter caps, and those might *conceivably* short out and cause problems, but they are also on the backplane, not on the CPU board. It is just barely possible that the SCSI controller itself is being destroyed, but that would be *very* difficult to do. Even plugging in the SCSI bus reversed won't do that. It is, of course, difficult to argue with the fact that 2 cpu boards have failed. Coincidences happen, but this is a bit much... | But this external mo-drive has been working perfectly for 9 months, | the SGI guy could not suggest what might be wrong with it, how we | could test it, or even what precisely was blown on the cpu boards, | and what might cause it - apparently they are shipped back to SGI and | the local engineer never gets to hear what the problem with them was. This is not really correct. See if you can get ahold of him ASAP, and have that board specially tagged for analysis in our logistics depot, and if they can't find the problem, by engineering. When that is done, the field folks get the results. In the normal case, they don't. | We really need that mo-drive. The only things we did before the | problems were to move buildings and add a second internal drive, | (Micropolis 2112) which seems to work fine. About the only other thing I can think of, until the board problem is determined, is to talk to the M-O drive vendor for any known problems with the SCSI interface (spikes, strange voltages, etc.) --- 5 --- >There simply isn't anything that I know of that can blow. The >termpower is protected by a PTF device, rather than a fuse, and >that is on the backplane rather than the CPU board. I did not see the start of this, but I can make one suggestion based on experience. Be very sure that all devices are plugged into the same circuit, and the same outlet on the same circuit. I have seen ground loops cause various bits of equipment to melt, explode, and stop working. I saw a printer combust this way, and personally killed serial port drivers on a 4D25. A transient ground loop of 10 volts might be possible on a 220VAC system, like yours in France. Typically the SGI and external SCSI device are only connected by the SCSI cable. This type of thing is not typically tested by system builders. If you are using part of a three phase setup, and have high powered switching equipement on another leg sharing common neutral, I'd bet lunch the voltage of common is being dragged around a bit too much. Less likely, but a real problem in this building is power distribution. The main power panel is through a wall at the end of a lab. The steel frame and conduit in that corner set up and antenna that makes all moniotor unreadable, and cause mysterious crashes. The control room of MIT's ALCATOR C-MOD fusion reactor finally went to a double optical isolation after a few-volt, few-million-amp ground fault caused a room full of Suns ( and other expensive equipment ) to turn to plasma. Reality is a wonderful teacher. Grounding problems can be hard to detect, and hard to fix. --- 6 --- There seems to be some difference of opinion about how easy it is to blow something on the Indigo cpu board by possibly malfunctioning SCSI devices, or by simply disconnecting a SCSI device without powering everything down. >| Well the sequel is that something to do with SCSI was blown on both >| cpu boards. On replacing the second, the SGI engineer asked me not >| to connect the external magneto-optic drive, and I've had no more >| problems for a week. > >There simply isn't anything that I know of that can blow. The >termpower is protected by a PTF device, rather than a fuse, and >that is on the backplane rather than the CPU board. > >There are also some EMI filter caps, and those might *conceivably* >short out and cause problems, but they are also on the backplane, >not on the CPU board. > >It is just barely possible that the SCSI controller itself is >being destroyed, but that would be *very* difficult to do. Even >plugging in the SCSI bus reversed won't do that. Yet, the local SGI engineer says that his colleagues (in Paris) have had to replace cpu boards after SCSI problems, and another user (perhaps he would prefer to remain anonymous) emailed me: >I blew up the SCSI drivers on my CPU board by disconnecting an >external SCSI device without powering down the system. >I'm 100% certain, because I did it twice. The first time, when >I forgot to turn off the Indigo, it fried the CPU drivers, the >second time an internal hard disk when I didn't turn off the >external CD-ROM. On the other hand, I have seen a (software) engineer unplug a CD-ROM drive from a running Indigo, and to my shocked question, replied that it was OK if the machine was not accessing SCSI. Mind you, the engineer in question was president of DECUS. Maybe he just didn't like Indigos ;-) --- 7 --- | There seems to be some difference of opinion about how easy it is to | blow something on the Indigo cpu board by possibly malfunctioning SCSI | devices, or by simply disconnecting a SCSI device without powering | everything down. Please, please, please! Since you have had support folks in Europe tell you that they have seen this problem, *have them get in touch with us in Mt. View*!!! I know it seems crazy to be asking a customer to have SGI field folks get in touch with headquarters, but unfortunately, I have no idea who these folks are. No similar reports (other than Alan's) have reached me internally, and if we have a problem, we need to know about it. I've very badly abused the SCSI bus, not once, but literally thousands of times, on dozens of systems, with hundreds of different peripherals, and never seen anything like this. So either something has changed, or we have a powersupply issue that shows up more on European power, or there are some common peripherals in Europe that we haven't seen, that trigger problems we haven't seen. | Yet, the local SGI engineer says that his colleagues (in Paris) | have had to replace cpu boards after SCSI problems, and another | user (perhaps he would prefer to remain anonymous) emailed me: | | >I blew up the SCSI drivers on my CPU board by disconnecting an | >external SCSI device without powering down the system. | >I'm 100% certain, because I did it twice. The first time, when | >I forgot to turn off the Indigo, it fried the CPU drivers, the | >second time an internal hard disk when I didn't turn off the | >external CD-ROM. There *are* no SCSI driver chips in Indigo. There is one, single, SCSI chip, with integral drivers. The only way I've ever been able to blow them is to solder them in wrong (and it is pretty spectacular; a good way to get a look at the die itself!). The only other components on the Indigo SCSI bus are passive (termination resistors, and filter caps). This is what has me confused and concerned. Again, to repeat what I said above, I have never seen reports of this, and not a whisper of any cases where something else on the SCSI bus was damaged! | On the other hand, I have seen a (software) engineer unplug a | CD-ROM drive from a running Indigo, and to my shocked question, | replied that it was OK if the machine was not accessing SCSI. | Mind you, the engineer in question was president of DECUS. Maybe | he just didn't like Indigos ;-) I've done it many times also. With the PTF (as opposed to a fuse), it is pretty safe. Mind you, it is *not* officially supported! (14) - Exabyte 8205 on an Indigo2 --------------------------------------------------------------------------- The subject pretty much says it all; I'm trying to get an Exabyte 8205 working on an Indigo2, IRIX 4.0.5H and am looking for a tpsc table entry for this drive, preferably one that supports both the EXB-8200 and EXB-8200c (compressed) modes. Thanks. A few days ago, I asked if anyone had a master.d/tpsc entry for an Exabyte 8205. Although I only got one response (w/ an entry for an 8505, not an 8205), using it together with the info the vendor gave me, the drive manual, and the similar info posted to this newsgroup previously, I was able to put together a working entry. The drive is now working happily in both standard and compressed modes. Below is the entry I used, as well as the mods. to /dev/MAKEDEV to create the device special files. To the best of my knowledge, the entry (and comments I make) below are correct, but of course, I can't guarantee this. Also, I haven't tested all the MTCAN_* options (eg, SEEK, SILI), but the drive manual says they're supported, so they *should* work (I don't know how the irix scsi tape driver implements these functions). -------------------- In /usr/sysgen/master.d/tpsc: /* Exabyte 8205: this drive supports two formats: EXB-8200 and * EXB-8200c (compressed). The SCSI command set used by this drive * is similar (if not identical) to the Exabyte 8500, so this * definition is based on that drive; the only difference is the * product ID string (tp_product[]) and the density values * (tp_density[]). Usage of the density modes is significant only * when writing, as the 8205 automatically selects the correct * density when reading. * * The meaning of the density values are as follows: * * Value Format Written Notes * ----- -------------- ----- * 0x00 EXB-8200c format This value is ignored by the drive if * used when writing to an EXB-8200 tape * when not at BOT (ie, EXB-8200 format * will be written instead). * 0x14 EXB-8200 format Using this value will return an error * (drive returns Check Condition status) * if used when writing to an EXB-8200c * tape when not at BOT * 0x7f No change The format written will be the same * as what is on the tape. If tape is * blank, then the drive power-on default * format will be used (set in EEPROM, usu. * 8200c format) * 0x90 EXB-8200c format Using this value will return an error * (drive returns Check Condition status) * if used when writing to an EXB-8200 * tape when not at BOT */ { EXABYTE8500, TP8MM, 7, 8, "EXABYTE", "EXB-8205", 6, "\40\4\16\0\200\7", {0x7f, 0x14, 0x90, 0x0}, MTCAN_BSF|MTCAN_BSR|MTCAN_PREV|MTCAN_CHKRDY|MTCAN_VAR|MTCAN_SETSZ| MTCAN_SILI|MTCAN_CHTYPEANY|MTCAN_SETDEN|MTCAN_SPEOD|MTCAN_SYNC| MTCAN_SEEK, 80, 4*60, 25*60, 5*60, 1024, 128*1024}, The mods to /dev/MAKEDEV are: *Device:*EXB-8205*) \ set v nrv nsv nrnsv ; \ for add in 4 5 6 7 ; do \ mdev=`expr $$minor + $$add`; \ mknod $${prf}$$1 c $$maj $$mdev; \ shift; \ done; \ for dens in 8 24 ; do \ case $$dens { \ 8) kden=8200;; \ 24) kden=8200c;; \ }; \ set "" nr ns nrns v nrv nsv nrnsv ;\ for add in 0 1 2 3 4 5 6 7 ; do \ mdev=`expr $$minor + $$add + $$dens`;\ mknod $${prf}$$1.$$kden c $$maj $$mdev;\ shift;\ done; \ done ;; \ This will create a total of 24 special files; 8 (nr, ns, nrns, etc) for each of the first three density values given in the tpsc entry (0x7f, 0x14 and 0x90 in the example above--I chose not to create special files for the 0x00 density value as this essentially has the same functionality as the 0x7f value). If anyone has any corrections to the information above, I'd be glad to hear them. (15) - Disks for Indy's --------------------------------------------------------------------------- We just ordered some INDY's. We had to order them diskless, because SGI's disk prices were too high (yes, we grumbled at our sales person about it). Of course, the next step is to order some 3rd party disks. One of the local SGI engineers told me the disks that SGI is shipping in the INDY are the Seagate ST3600 and ST31200. Is this correct? I called our usual supplier, and got the following prices: ST3600N - 525Meg 3.5" low profile disk $859 ST31200N - 1052Meg 3.5" low profile disk $1544 ST11200N - 1.2Gig disk, in tabletop enclosure $1389 The prices for the first 2 includes a 1 year on-site maintenance contract. The third disk price includes 3 years on-site maintenance, and a 5 year warranty. All the disks are fast SCSI-2. Any reason not to buy the ST11200N? It is cheaper and slightly larger (in Meg) than the ST31200. Also, since it is in an external enclosure, the INDY power supply won't have to work as hard, and it will be easier to move disks around (some people were saying it is difficult to get at the INDY internal disks). One more gotcha, the quote said "ST31200 available late November". As long as you don't mind the extra enclosure, it should work fine (no promises though). The 11200N is what we are selling on the Indigo2. Make sure you get new enough firmware that it doesn't have the "goes away and won't respond to selection" bug. The difference in the load on the power supply in the Indy will be negligable. (16) - Indy Graphics --------------------------------------------------------------------------- |> We have an Indigo with XS24 graphics. We've written an application that |> uses a double-buffered 12-bit plane for images and a 4-bit |> overlay plane for xwindow controls. I am thinking of buying an Indy SC |> soon with 24 bit graphics to host this app. Can this machine |> handle the same visuals as the Indigo? |> |> Not quite. The 24-bit Indy graphics does support 12-bit double-buffered (both pseudoColor and TrueColor) but it has two overlay visuals of depth 8 and 2, rather than the three overlay visuals of depth 2,2 and 4 of the XS24 Note that the 4-bit overlay visual on XS24 shares bit planes with the two 2-bit visuals. The Indy 8 and 2-bit overlay visuals are completely independent (i.e., separate bit planes). (17) - VME Interrupts --------------------------------------------------------------------------- How are the VME interrupts (Levels 0-7) mapped to the CPU interrupts? I have a VME board that is triggering VME Level 5, 6 & 7 interrupts. I can see the interrupt lines asserted on a logic analyzer. However, for some unknown reason only Level 5 gets to the kernel. Levels 6 & 7 don't do anything. I know that the kernel routines spl0, splnet, splvme, ... can be used to block interrupts at the CPU, is there a similar routine to mask VME interrupts at the VMEinterrupt handler? How about hardware jumpers? Could I have something jumpered incorrectly that would mask certain VME level interrupts? I'm almost positive that /usr/sysgen/system is setup correctly for the other levels. Any Ideas? --- 1 --- First, you should get the Device Driver Writer's Guide, which talks about a lot of these issues. The answers vary from system to system. For the low end systems, there is only one VME interrupt to the cpu, and the vector is then used to determine which device interrupted. I don't remember how this works on the high end, but I think it is similar. --- 2 --- I have just one quick addition to what Dave said here. We do mask individual VMEbus levels before they get to the CPU. This is vital to allow for us to respond to only certain VME interrupts, while allowing another interrupt handler to take ones not intended for us. At kernel generation time (lboot, autoconfig), the system determines which VME device drivers are going to be built into the kernel, and puts them on a list. Then, at system start up time, for each device, the corresponding VMEbus interrupt level is unmasked. So, if you are seeing the interrupt get through on some levels, but not on others, you probably just have your kernel configured with device drivers for those levels that do get the interrupt. To see which devices are being configured in, you can run lboot with the -v option which will print the results of the probes for devices. Then, you can compare that with the levels for those devices as specified in the sysgen/system file. (18) - Extending Keyboard, Mouse and Video signals --------------------------------------------------------------------------- We're finishing ordering our new ONYX with a RE^2 and two Raster-Engines. We need to drive the video about 150 feet, in an optimal setup(tm) . It's not my idea(tm) but a guy who wants to run Alias that far from his ONYX/RE^2. SGI kindly sells for a very attractive(!!) price a 75' kbd/mon/rat extension. Can you hook two(2) together, or do you have to go to some(please fill ________________) vendor(_______phone #) to get a longer one with an amplifier?? --- 1 --- Technically, yes, but your image on the monitor would be unacceptably dim. You need some sort of amplifier. --- 2 --- There are two companies that I know of that can connect the keyboard, mouse and monitor to an SGI system separated by 150' or more. I have the address and phone for one, but not the other. The one I don't have the address for is called Lightwave Communications. I've seen ads for them in some of the Unix magazines. The one I do have info for is: Meret Optical Communications, Inc. 1800 Stewart Street Santa Monica, CA 90404 PH: (310) 315-1422 Both of these companies send the keyboard mouse and video information over fiber optic links with a box at each end. It's more expensive than a straight cable, but can be extended to much more than 150'. --- 3 --- >the other. The one I don't have the address for is called >Lightwave Communications. I've seen ads for them in some >of the Unix magazines. LightWave Communications 84 Research Drive Milford, CT 06460 (203) 878-9838 (19) - More SCSI for Challenge M --------------------------------------------------------------------------- Is there any chance that SGI will have additional SCSI bus cards for the Challenge M? We are currently using our machines for "small" projects, and there is the chance that they may need more disks on the machines. Does or will SGI sell a card that will do this? --- 1 --- Such a card is being worked on. I don't know if it will be a product or not. Talk to your sales folks. If done it would likely be a wide/fast SCSI channel, possibly differential. It would be nice to get more than one channel, but i/o panel space is the limiting factor. --- 2 --- You might also consider the new 2.0GB internal disk for the Challenge M. (20) - Device Driver Guide for 4.x versus 5.x --------------------------------------------------------------------------- >You can order M4-DVDR-2.0 for IRIX 4 and M4-DVDR-3.0 for IRIX 5. How different are the two manuals? If I get M4-DVDR-3.0 will it cover IRIX 4 info as well? I'd only like to get one manual and we're currently working with IRIX 4.0.5, will I be able to tell the differences between 4 and 5 in M4-DVDR-3.0? The one for IRIX 5 has *some* info that talks about the differences, and there is a lot of stuff that didn't change, but in general, you *really* want the one for the O/S you are working with. There were a *lot* of changes in kernel internals from 4.x to 5.x (relatively few between 3.x and 4.x). (21) - Trouble with Indigo Disk Drive --------------------------------------------------------------------------- I need some help with my system disk /usr partition. When I boot the system (INDIGO R4000) I get a error message from fsck that BLOCK 1 is bad!. I've tried using fsck -g /usr/dsk/dks... and I get the message: Primary superblock inaccessabe or invalid. Trying secondary. No filesystem on /dev/dsk/dks0d1s1. Message repeated about 30 times. Can this be fixed??!! Sounds like the drive isn't responding at all. Are you sure the drive ID wasn't changed, and that the drive was recognized? (Check the hinv output). Looks like it is seen OK, from the message you show above. Can you bring up fx on the drive? Why are you trying partition 1 on drive 1? That is normally the swap area, and the only time it will normally have a filesystem is when the miniroot has been loaded and booted (it gets copied to the swap area). (22) - Bru for floptical? --------------------------------------------------------------------------- Can anyone tell me if bru will work with floptical drives ? Probably (I've never tried it), but I doubt that multivolume will work unless you specify the right -s option value. (23) - Using serial port to detect a switch closure --------------------------------------------------------------------------- I need to write a program to act as an external switch on an Indigo. I've tried using cxPortAccess routines but I guess my makefile isn't working correctly and even if it was I'm still just guessing. Can anyone help me with a few lines of code which would detect a switch closing across a few pins on a modem cable plugged into the serial port and then trigger a frame grab. Even a partial solution would be greatly appreciated. You can post here or mail me either as winsorr@cuug.ab.ca or better still 73223.2374@compuserve.com. (I get my compuserve mail more regularly than my real Internet mail...sigh.) Thanks, I have a solution. The switch can be done by a tiny program. I fopen /dev/ttym1. The program hangs until I short pins 4 and 8. The video capture I got from usr/people/4dgifts/sv/examples/video/indigo Filename oneframe.c (24) - Toshiba XM3401BC on Indigo --------------------------------------------------------------------------- I just bought a CDROM Toshiba XM3401BC from a third party which I cannot connect to my Indigo XS. No matter which SCSI address I use, the hinv command doesn't show me any CDROM. Maybe I was misinformed and this CDROM cannot be used on Indigos or I need a patch for this CDROM. I hope somebody can give me a hint or some other information about this CDROM. --- 1 --- Are there errors on the console during boot? If correctly connected, almost any CD-ROM drive should at least show up in the hinv output, even if it doesn't work correctly. Some might show up as a disk, in some weird cases, but they should show up. Are you sure it is connected, terminated, and powered on? --- 2 --- During booting I got a message for nearly one millisecond which I found in /usr/adm/SYSLOG : Oct 7 13:39:56 dix syslogd: restart Oct 7 13:39:56 dix unix: IRIX Release 4.0.5F IP20 Version 08280217 System V Oct 7 13:39:56 dix unix: Copyright 1987-1992 Silicon Graphics, Inc. Oct 7 13:39:56 dix unix: All Rights Reserved. Oct 7 13:39:56 dix unix: Oct 7 13:40:00 dix inetd[120]: /usr/etc/rpc.snoopd: No such file or directory Oct 7 13:40:00 dix inetd[120]: /usr/etc/cvpcsd: No such file or directory Oct 7 13:40:00 dix inetd[120]: /usr/etc/podd: No such file or directory Oct 7 13:40:00 dix timed[131]: slave to cicely Oct 7 13:40:02 dix sendmail: starting Oct 7 13:40:06 dix syslogd: restart Oct 7 13:40:08 dix lpsched[178]: can't open output queue file Oct 7 13:40:08 dix FaxServer[205]: OPEN "/dev/ttyd2" Oct 7 13:40:11 dix cdromd[211]: /dev/scsi/sc0d4l0 is not a valid CD-ROM drive Oct 7 13:40:11 dix /usr/etc/cdromd[210]: Unable to start mount daemon for /dev/scsi/sc0d4l0 on /CDROM Oct 7 13:40:41 dix Xsession: root: login Oct 7 13:40:44 dix Xsession: root: all hosts being allowed (access control disabled) The file /etc/fsd.auto looks like follows: /dev/scsi/sc0d4l0 /CDROM cdrom ro 0 0 The CDROM is connected, terminated and powered on, so this cannot be the problem. Even the SCSI address is set to four. I hope this information is of any help. --- 3 --- Does it show up in the PROM hinv? Does anything else in hinv look strange (like more disks showing up than you know you have, or anything else at SCSI ID 4)? Can fx open the CD (fx -x 'dksc(0,4)') ? Is there media in the drive (ISO9660, or EFS)? If fx can open the drive, what does it show for the inquiry info (should be similar to this; which is for the older SGI version of the Toshiba 3301): ...controller test...OK Can't get drive geometry, assuming 64 sectors/track Can't get drive geometry, assuming 8 heads Unable to get device geometry, assuming default Scsi drive type == TOSHIBA CD-ROM XM-3301TA1971 --- 4 --- Maybe he isn't turning the CD-ROM on BEFORE turning on the Indigo. One needs to turn on ALL SCSI peripherals FIRST and the Indigo last. If you don't, the system will NOT know the device is there. --- 5 --- To whom it may interest: I found the problem I had with my CDROM Toshiba XM3401BC. It was just as simple as two cables which were badly connected in the CDROM case. So it didn't matter which SCSI address I used, in the device it was either zero or one. One thinks that these components are checked before leaving the factory. At this point I want to thank all the people who answered my inquiry and tried to help me. (25) - Software protection --------------------------------------------------------------------------- Does somebody know a software protection method which guarantees that the software can only be used up to a specific date? Or, is there any hardware time available which is absolute and cannot be set or manipulated, and how can this time be got? --- 1 --- No, there is no time on any SGI system that can't be changed by the user. --- 2 --- Usually people compensate by making a program which scan the disk for file access times, If it finds any file access time which are ahead of the current date, then it blows up the program. Also you can create a file on installation of the program, touch it with an start date, then imbed that date into the file. (encoded with your own encryption key) When starting up the program, check the creation date of the license file to make sure that it is the same as the imbedded date, and the system date is prior to or after that date. (depending on whether you want a 30 day type license or a termination date license.) I've found several (which won't be mentioned) vendors which do not monitor the system clock at all making it easy to extend licenses. (26) - Using 'setmon' --------------------------------------------------------------------------- In Pipeline's september/octopber 93 edition, page 19, there is a table that says that Indigo XZ24 systems can produce component RGB signals by using a setmon command. Do you confirm this ? I tried to use setmon but the system doesn't recognize the command. Try /usr/gfx/setmon. The /usr/gfx directory is not normally in a user's path variable. (27) - Fastest Baud rate for serial ports --------------------------------------------------------------------------- What is the fastest baud allowed for serial port on an Indigo R3K or R4K ? 57.6K, 38K or only 19.2 ? 38400bps is the fastest async rate on the serial ports. (28) - Odd baud rates --------------------------------------------------------------------------- I have someone here at work that needs to access the serial port at a baud rate different than the presets. It's like 32000 baud. Is there a program that can set the serial port to odd rates ? Not really. When put into 'EIA 422' mode, as is done with midi, it can sync up to an external clock. That *might* do it, I don't know. (29) - SCSI Devices on Twin Tower machines --------------------------------------------------------------------------- We are investigating the addition of a DEC CDROM to our SGI 4D/220GTX. THis is a dual tower machine with an integral tape drive in the power supply tower, and a hard disk stacked on top. Inside the disk module are standard scsi 50 pin IDS connectors, two on an interface board that interconnects from the device stacked below. I would imagine we could disconnect one of the IDS connectors and attach a flat ribbon cable with an adapter for the centronics type external cable, like the DEC and most other external scsi devices. WHich one of the connectors should we disconnect? SHould we install an terminator on the CDROM? The CDROM isn't intended to become a permanent fixture in the SGI, so we might like to install an external type scsi connector somewhere. My instincts lead me to beleive the cleanest way to do this would be buy one of the stackable modules for expansion, and install a connector on the back. I believe these are available, anyone have the source? --- 1 --- >how do we install a terminator on the CDROM? There are two ways the right way and the cheap way. The right way: Order a P5-Xscsi - twin tower drive expansion tray, This tray includes and external scsi on the back, with a centronix style terminator The cheap way: If you already have an IO3 board (type hinv) then the second scsi bus can be brought to the backplane in a centronix type connector. (I'm not certain if this modification was ever approved (FCC)) There was talk about doing that. If you don't have an IO3 (Older gtx's have IO2) an IO3 upgrade may be costly but will bring you performance and flexability. Talk to your local SE or SSE they should be able to give your prices and performance numbers. (30) - Connecting Video Projectors to SGI platforms --------------------------------------------------------------------------- We're trying, without success, to connect a Crimson to a SONY video projector, one of those gizzmos you see in lecture rooms that takes a computer's display output and projects it to a large screen. The projector has a red, green, blue, and sync inputs. The Crimson has a red, green, blue, and sync outputs. We connect everything and get nothing! How does one do what we want to do? Is it possible? Is special aux. equipment needed? --- 1 --- This is commonly done. The most likely problem you have is that the projector isn't compatible with the high-resolution video coming from your Crimson. You may (depending on the type of graphics board in your Crimson) be able to change your video output to something that the monitor can display. See the setmon(1G) man page. You might also turn off sync on the R, G, and B guns (setmon -sn) since most projectors object to it. --- 2 --- When we hooked up a Barco projector to the crimson, the Barco was not able to scan fast enough for the output rate of the VGX. The barco was later upgrade to support upto 80 Hz. Also by default the sync signal is on the green output from the crimson. (31) - Using 'sysid' for software licensing --------------------------------------------------------------------------- We distribute software for SGI machines. The software is licensed so that it only runs on one machine. This is implemented by reading the sysid in the program. Now the other day a strange thing happened - a customer requested a license for one machine ID, and we sent it to him, no problem. BUT: A day after we got a fax saying, "because we run some other software on this machine, this software makes other programs think that the sysid is different", i.e. without this (unnamed) software, the sysid would be 69xxxxxx, and when it is running, the sysid returns 12xxxxxx to other programs. Can this really be true? The code (our program) is not linked against shared C library (-lc_s) === so this can't be the problem. If this is true (and I have no reason to believe otherwise), is there a way of getting the "true" sysid always? | This is implemented by reading the sysid in the program. How? Are you actually using sysid(), or are you doing something else? The only way sysid() can change is with hardware changes, or on Onyx/Challenge, when 5.1 is installed (to fix a bug in sysid that caused duplicate id's in 5.0.1). If you are using something other than sysid(), you need to tell us what you are using. I have some strong suspicions on what you are doing based on the numbers you included, but I'd like to have you confirm them. (32) - Books about MIPS processors --------------------------------------------------------------------------- I'm searching for something about the R3000/R4000 RISC processor (architecture, instruction set, etc.). (To teach computer architecture at the ELTE Univ. Budapest.) Book: MIPS R4000 Microprocessor User's Manual by Joe Heinrich; PTR Prentice Hall Englewood CLiffs, New Jersey 01632 QA76.8.M523H45 1993 (33) - Wangtek DAT on an Indy? --------------------------------------------------------------------------- Is it possible, to connect a Wangtek DAT-SCSI-Streamer Model: W6200HSX (2GB DAT) to a SGI Indy? Probably, but no guarantees. You'll need to edit /var/sysgen/master.d/tpsc (34) - DAT drive on Power Series Systems --------------------------------------------------------------------------- According to SGI it is not posible to put a DAT (4mm) drive on this old Power Series system. Is this really true, or is there a way to do this? We have one of these with 2 1.2 gig disks, and no good way to back it up except by get a couple dozzen DC6150 tapes and having someone babysit the box, swapping tapes. Backing it up over the network is not a posiblity (its only connection is a slow (19.2K BPS) SLIP connection through an Onyx (which is very sensitive to massive data streams (drops the connection)). --- 1 --- I believe that the DAT was never released on the older twin tower systems (FCC, etc. testing was not done). But if you can somehow connect a DAT to your system, and the DAT is like the one SGI sells, it should work, as long as the SCSI connections, termination, etc., are right. [See (29) ] --- 2 --- We have an HP DAT drive on a 4D/240S which works just fine. If you don't need the drive to support audio and can live with an external drive, it will work for you as well. Supporting compression is a bit more tricky and we didn't try it here so I cannot tell how is it like. (35) - Serial Port & Modem Cabling for Indigo --------------------------------------------------------------------------- I read the SGI faq - no help. I read the owners manual - It said a twisted pair (for mac ) will work (3 wires), But no comment on hardware handshake except 'You can buy it from SGI'. --- 1 --- I'm going to assume you're talking about an R3K Indigo. From the "IRIX Advanced Site and Server Administration Guide", chapter 7 (available on-line through IRIS InSight): ------------------------------------------------------------------------ Mini-DIN8 Connector Cabling There are 3 basic cable configurations for the Mini-DIN8 serial ports. See your Owner's Guide to determine if you have a Mini-DIN8 port on your workstation or server. Depending on the cables used, some functionality may be sacrificed. Note that the pinout of these Mini-DIN8 connectors is different than that of the DIN connectors on larger systems. These larger systems also have DB-9 connectors that are connected to the same internal port hardware. For most dumb terminals you should use a commercially available ``MAC SE(R) to Imagewriter1(R)'' cable. This cable would use the normal 3 wire connection and be used as a /dev/ttyd* device. Table 7-5 shows the pin configuration: Table 7-5 Mini-DIN8 Serial Terminal Cable Function Mini-DIN8-Male DB25-Male 1 nc TXD 2 nc GND 3 3 RXD 4 7 5 2 DCD* 6 nc GND 7 20 8 7 * /dev/ttym* devices should be used with this cable only if the system must notice when the terminal or printer is powered off. Note: A MAC SE cable also has some other pins connected but they can be ignored. For modem devices using RTS/CTS hardware flow control the following pin-out will allow ``full flow control.''' This cable is required to implement /dev/ttyf* devices. This cable will also support /dev/ttym* devices. Table 7-6 shows the pinout: Table 7-6 Mini-DIN8 RTS/CTS Modem Cable Function Mini-DIN8-Male DB25-Male DTR 1 20 CTS* 2 5 TXD 3 2 GND 4 7 RXD 5 3 RTS* 6 4 DCD 7 8 GND 8 7 * RTS and CTS are ignored (optional) if using /dev/ttym* but required if using /dev/ttyf*. Note: This cable is available from Silicon Graphics. Contact your sales representative or SGI Express. This cable can be used with a null modem adapter for terminals and printers (see Table 7-2 above), though you should use this cable exclusively for modem connections. The commercially available MAC SE to modem cable (``off the shelf ''') will not work properly with SGI software. --- 2 --- Generic Mac modem cables will not work (not enough pins) to support high-speed (V.32 and faster) modems that require hardware flow control and modem control lines. You can make your own cable -- the pinouts are in `man serial`. SGI does sell the cables, and places like INMAC will make them custom. (36) - FDDI/CDDI on Indigo2 --------------------------------------------------------------------------- The last I heard, SGI expected to have cddi for the Indigo 2 Extreme about 4Q93. Is it still expected within this timeframe? Cost?? Will this fit into the backplane of an Indigo 2 Extreme, or do the graphics cards cover the ports? --- 1 --- The FDDI (fiber) board is now available. Twisted Pair FDDI will likely be available around 4Q93, at least from an engineering stand point! You'd have to contact your local sales person to see when those wacky marketing folks intend to sell it. I'm not exactly sure what it's cost will be. >Will this fit into the backplane of an Indigo 2 Extreme, or do the >graphics cards cover the ports? The slot scheme on Indigo2 is confusing and goofy. You can have one Extreme Graphics board set and one FDDI (or one FDDI-TP) board stuffed at the same time. This maxes out the slots. You couldn't fit the video option or any EISA cards in addition to Extreme and FDDI. --- 2 --- | The last I heard, SGI expected to have cddi for the Indigo 2 Extreme | about 4Q93. Is it still expected within this timeframe? Cost?? Last I heard, it was still waiting for the standard to be approved. That is either close, or just recently happened (I've lost track). I haven't heard release date info. | Will this fit into the backplane of an Indigo 2 Extreme, or do the | graphics cards cover the ports? It occupies the same amount of space as the fddi board for the Indigo2. You can put Express graphics and fddi/cddi in the same system, but that fills all the slots (no room for EISA or other GIO boards). With XZ or XL graphics you would have room for an EISA card also, but both GIO slots would be full. (37) - Apple (or other) CD-ROM on SGI --------------------------------------------------------------------------- There seem to be a few posts lately where people want to use CDROMs with their beautiful Indigos etc. Because we're poor ;-< and can't afford an Indigo, I need to mount a (iso9660?) CDROM drive on our ol'faithful Iris 4D20/GT. Because we're *really* poor, my colleagues would very much appreciate it if this CDROM drive could also be used on our Macintoshes and PCs! - not all at the same time though! I'm sure someone else out there must have similar requirements/limitations... how do you handle such a situation? My thoughts were to get an Apple 300i (I have a Mac in my office!) to kill at least two birds with one stone... Will this work on the 4D/20 and Irix 3.3.1?? Any other suggestions? --- 1 --- Nobody has posted any success stories on this, although many have asked, and some have tried. Aside from the fact that you really need the SGI version to be able to install on old machines like the 4D/20, you need the 512 byte sectorsize default, and that really upsets Macs. I've yet to find a CD-ROM drive for the Mac that has a 'standard' enough SCSI implementation to work on any SGI system, even those like the CD300 from Sony, which is supposed to be a fairly standard drive. Presumably Mac's need some unique firmware changes in CD-ROM drives also, and it just doesn't want to work. (38) - Connecting Tektronix color printer to SCSI port --------------------------------------------------------------------------- We have a 4D/310 VGX with no parallel port and a textronics color printer with no serial port. Both have available SCSI ports, can we make them talk in a short period of time? Our SA guy is fairly new, and not very optimistic. I know we have 3 different SCSI printers tested, and 2 of them supported at this time (Seiko and Genicom/SRS). The folks at Tektronix in their printer group have been in fairly close touch with the Impressario folks at SGI at various times, so why not ask your Tektronix support folks. (39) - Disks for Challenge L --------------------------------------------------------------------------- I am configuring a Challenger L with some Maxtor MXT-1240S drives. These are jumper configureable single-ended/differential Fast SCSI-2 1.2 MB (formatted) drives. (1) Other than the obvious need for SGI drive sleds to allow power connection in the bays, are there things to look out for when selecting a drive? (2) Is the above drive known to work? (3) What type drive does SGI use by default for the 1 GB and 2 GB option? I had some very bad experiences with the early 1240 firmware, in terms of reliability (fixed pretty much, by the last version I tested) and performance (not fixed by the time we gave up on them; don't know if it was later or not). I don't think the 1240 was ever tested against challenge at all. The officially supported drives are OEM versions of the 1.2 and 2 GB IBM drives. (40) - Multichannel Option Problems --------------------------------------------------------------------------- We just got an Multichannel Option board for our RE2 Onyx (with two raster manager boards). So far we can't seem to get it to go into the Multi-channel mode. if we do gfxinfo, we get: Graphics board 0 is "REV" graphics. Managed (":0.0") 1280x1024 Display 1280x1024 @ 60Hz 12 GE (GE10 rev. 0x7) 2 RM boards Medium pixel depth 10-bit RGBA pixels Not using Multi-Channel Option according to our reading of the MCO manual we should be able to simple do something like: setmon -S 2@1280x1024_60 and we get: setmon: internal error in /usr/gfx/ucode/RE/vs2/vof/2rm/1@1280x1024_60/ vs2_vof0.u several other settings were tried, all but a few gave the same error. One that did sort of work was: setmon -S 2@1200x900_72 but our monitors couldn't handle that (image wasn't syncing or sized right). gfxinfo gave: Graphics board 0 is "REV" graphics. Managed (":0.0") 2400x900 MCO Display 0 1200x900 @ 72Hz, origin (0, 0) MCO Display 1 1200x900 @ 72Hz, origin (1200, 0) 12 GE (GE10 rev. 0x7) 2 RM boards Small pixel depth 10-bit RGBA pixels Driving Multi-Channel Option Anyone have any idea what we need to do to get the 2@1280x1024_60 to work (when not in MCO mode our normal mode is 1280x1024_60, i.e. the monitor(s) we want to drive are 1280x1024 at 60 Hz). We could conceivably wait for our local SGI guy to come back from vacation, but we'd like this to work soon. --- 1 --- You didn't say what version of software you are running. The message above indicates that the file "/usr/gfx/ucode/RE/vs2/vof/2rm/1@1280x1024_60/vs2_vof0.u" does not match the version of Irix that your system is running. You would see this if you were trying to load VOFs from 5.0.1 under 5.1 or vice versa. You need have a matched set of VOF's. I would guess that the following happened: Your system is running 5.1 which already contains MCO support. The SSE installed an MCO and loaded the 5.0.1 MCO software. This CD only contains MCO vofs so it would not affect the system in any other way. You now have a 5.1 system with MCO vofs from 5.0.1. Re-loading eoe1.sw.unix from 5.1 should fix this problem. --- 2 --- Well we finally got it to work by copying the appropriate files from another Onyx system. Seems our files were corrupt (not even the same number of bytes in length). Now for another question, when we put it into 2@1280x1024_60 mode we do indeed get display on two monitors and each is 1280x1024. Unfortunately as far as X is concerned this is being managed as one large screen/display. That is, X treats this the whole thing as :0.0 and it is 1280x2048 with the top half of this display on the first monitor and the second half of the display on the second monitor. This has undesirable artifacts, things like: the dogfight is stretched out to cover boths displays (the scene on one monitor, the instruments on the other, and the aspect ratio all wrong); the initial login screen (pandora's box) is stretched across both screens; etc. This isn't really the way we want it (though I suppose we can live with it for the application we bought the thing for). It would be much nicer though if we could convince X that this is one display with two screens. That is, have a :0.0 and a :0.1 with :0.0 on one monitor and :0.1 on the other monitor, with each screen being 1280x1024. Is there any way at all to do that? --- 3 --- >Well we finally got it to work by copying the appropriate files >from another Onyx system. Seems our files were corrupt (not even >the same number of bytes in length). Either corrupt, or they were the older 5.0.1 vof files, which were shorter in length than the 5.1 vof files. > >Now for another question, when we put it into 2@1280x1024_60 mode we >do indeed get display on two monitors and each is 1280x1024. >Unfortunately as far as X is concerned this is being managed as >one large screen/display. That is, X treats this the whole thing >as :0.0 and it is 1280x2048 with the top half of this display on >the first monitor and the second half of the display on the second >monitor. This has undesirable artifacts, things like: the dogfight >is stretched out to cover boths displays (the scene on one monitor, >the instruments on the other, and the aspect ratio all wrong); the >initial login screen (pandora's box) is stretched across both >screens; etc. > >This isn't really the way we want it (though I suppose we can live with >it for the application we bought the thing for). It would be much nicer >though if we could convince X that this is one display with two >screens. >That is, have a :0.0 and a :0.1 with :0.0 on one monitor and :0.1 on >the other monitor, with each screen being 1280x1024. > >Is there any way at all to do that? > No; the problem is that the gfx device driver was not written to support multiple screens per single graphics pipe. It is unlikely to be changed to support this in the future. Most applications which use the MCO can't afford the gfx context switching overhead that they would incur when switching from screen to screen anyway, so implementing the 'multiple screen per gfx pipe' feature is a solution in search of a problem. Of course here at SGI, I just sit down at the Onyx/MCO and start typing away into wsh's and wish for the multiple screen X server too. There is a solution, if you want to throw $$$ at it; you can order a triple pipe server from SGI, and then you get :0.0, :0.1, :0.2. Then you get the same problem all over again if you put MCO's in each pipe :-) (41) - Flicker on Indigo2 --------------------------------------------------------------------------- I've just setup an Indigo^2 XL (with the 19" monitor), and the screen display has a strange flicker to it. There is another large monitor in the same room, but turning it off didn't affect the Indigo monitor. I tried playing around with the adjustments on the monitor's remote control, but nothing seemed to make a difference. Has anyone else seen this? --- 1 --- Sounds like a timing problem with the prototype hardware. You might try '/usr/gfx/setmon 60HZ' if so, to see if that helps. If you got a demo unit or loaner early on, you might not have the late, but in the MR released software, changes that are also needed. I suppose it might also simply be a syncing up with flourescent lights or the like; does it still occur with the lights off? --- 2 --- I did this and the flicker went away. Here's the session: random 1# /usr/gfx/gfxinfo Graphics board 0 is "NG1" graphics. Managed (":0.0") 1280x1024 24 bitplanes, NG1 revision 3, REX3 revision B, VC2 revision A MC revision C, xmap9 revision A, cmap revision B, bt445 revision A Display 1280x1024 @ 72Hz, monitor id 9 random 2# /usr/gfx/setmon 60HZ random 3# /usr/gfx/gfxinfo Graphics board 0 is "NG1" graphics. Managed (":0.0") 1280x1024 24 bitplanes, NG1 revision 3, REX3 revision B, VC2 revision A MC revision C, xmap9 revision A, cmap revision B, bt445 revision A Display 1280x1024 @ 60Hz, monitor id 9 random 4# Is it possible to use a higher refresh rate on an Indigo^2 XL? I thought it had the same graphics as the Indy, which is supposed to use a refresh of >= 72Hz? >I suppose it might also simply be a syncing up with flourescent >lights or the like; does it still occur with the lights off? No, turning off the lights didn't make a difference. --- 3 --- 72, but not 76. As I said, it sounds like you have pre-MR hardware and/or software. The MR stuff does work at 72. --- 4 --- On a similar note, is there a way to setup an r3k Indigo, with IRIX 4.0.5F, to boot up in 72HZ video mode? I am currently using a DEC 19" monitor that only syncs @ 72HZ and I must do an rlogin and /etc/gfx/setmon 72HZ in order to see and use the console. --- 5 --- How can I track down whether it is a hardware or software problem? Does this help?: % uname -a IRIX random 5.1.1 09101811 IP22 mips % /usr/gfx/gfxinfo Graphics board 0 is "NG1" graphics. Managed (":0.0") 1280x1024 24 bitplanes, NG1 revision 3, REX3 revision B, VC2 revision A MC revision C, xmap9 revision A, cmap revision B, bt445 revision A Display 1280x1024 @ 60Hz, monitor id 9 And one more question, is there some way to make 60Hz the default until our hardware/software is updated. Right now, I have to re-set the mode any time the system is rebooted. Is there a prom variable I can set? (42) - Fuji M2263SA on an Indy? --------------------------------------------------------------------------- Anybody sucessfully config a Fuji M2263SA 5.25" drive for an indy? I have: SCSI-2,No Synchonous, rest factory defs. and fx can ALMOST format it... --- 1 --- So what errors do you get? I might be able to suggest something that would help. --- 2 --- Doesn't Indy support Fast-SCSI-synchronous-transfers? --- 3 --- Yeah, but Fujitsu doesn't ;) At least, if it is like the earlier 2263 drives, they don't handle the sync negotiation correctly. Maybe that's been fixed... --- 4 --- Latest info on the Fuji M2263SA config: drive is configred as: External M2263SA drive, SCSI address 5 All manufacturer defaults SCSI-1/CCS instead of SCSI-2 Synchronous mode disabled connects to a Indigo R3000 Entry system IRIX 4.0.5F, running: % fx -x does an AUTO mode just fine. Formats and verifys disk with no problems or messages. Doing a mkfs on the drive works like a charm. Now physically remove the drive, connect to an Indy. >>setenv tapedevice bootp()remotehost:/CDROM/dist/sa >>boot -f $tapedevice(sashARCS) --m ROM GUI reports: copying installation tools to disk... then monitor console request sense failed io failed... Apparently there are some real problems with the SCSI driver on an Indy, since this same drive and cable works fine with: NeXT systems (NEXTSTEP 3.0 and 3.1) SUN sparcstation 1 systems (Solaris 2.0) IRIS R3000 entry (IRIX 4.0.5F) --- 5 --- Note that Indy actually runs at sustained fast SCSI rates; Indigo does not. Your cable may well be not be good enough. External cables are strongly recommended to be as high quality as you can get (like ours ;)) and in no case longer than 2 meters. In any case, it clearly isn't the same cable you used on Indigo, they have different connectors... Of course, if sync mode is truly disabled (as opposed to perhaps target initiated sync being disabled), then it isn't running at fast scsi rates, but even so, cabling could be an issue, as you can hose the internal drive since it is on the same SCSI bus. --- 6 --- So it should be possible to use a Fujitsu M2624FA (3,5", Fast-SCSI-2) in synchronous-mode with the Indy. Right? --- 7 --- Fast SCSI works in Indy, no doubt about it. Whether that particular drive will work, I can't say. I will say that people have had more problems with Fujitsu SCSI drives on SGI equipment than most other brand drives, for some reason. --- 8 --- While I profess to know nothing about the INDY ( the pricing structure for them and the features my clients need adds up to a win for the Indigo2 all the time ), some people seem to be having real problems with Fujitsu disk drives on some SGI boxes. The following models 2624-FA ... note *F* -> fast 2652-SA 2654-SA 2694-SA should all work as FAST SCSI-2 drives, although some of the early revisions of the 2652-SA had real problems related to caching, but the fixes are reasonably readily available. The following models, 2263-SA 2266-SA 2624-SA only work as standard SCSI-2 drives. They do work as SCSI-1/CCS but that is not the issue here. In the area of caching, there were real problems with the early firmware revisions of the first two models, although Fujitsu is not alone in this area of SCSI firmware problems. While some of this was caused by Fujitsu trying to pander to all the sorts of peculiarities of machine makers ( they even had a special revision of the firmware for the 2266 to make it behave on DEC workstations ), the industry was still learning about SCSI-2 at that time - most workstation vendors only offered SCSI-1/CCS then anyway, and even then, they had problems getting their device drivers right. For those who are using Fujitsu drives on SGI equipment, those that have problems, and those that may not, I would suggest posting to the group, the - model number of the drive, and - age of the drive, - hardware revision level, and - firmware revision level, and - jumpers connections, and - actual problem symptoms, and - OS revision, and - target machine, and I would also be personally interested if you purchased the drive from your local PC disk vendor or from somebody who actually knows something about disk drives on high performance workstations. BTW, I have never learnt or even understood what factory defaults are so I get lost when people mention them and maybe many others do too. Unfortunately, when talking about defaults, we are sometimes referring to what has been delivered, as opposed to what the factory in Japan uses. Maybe, with this set of results, it may become obvious, to the world at large, what the problems really are. (43) - 4D/25 Boot problem --------------------------------------------------------------------------- I have a 4D/25 under my wing which has many problems... The system disk developed bad sectors, and I tried to use fx to reformat, and do a butterfly test to find bad sectors. It didn't report any errors, so I tried to install a new system from the original install tapes for Irix 3.2. Unfortunately, it wouldn't let me mount the /usr partition, saying that the filesystem was dirty. I fsck'ed it, mkfs'ed it, and reformatted it, but none of these helped. Now I can no longer access the fx program, and I tried to boot off of the sash file, but I get an Invalid Byte Order message. How can I reformat the drive now? I cannot access the fx, so I cannot format. Any helpful hints? Also, what kinds of upgrades are suggested for this system, or is it adding fuel to a dead fire? The machine only has 8mb RAM, 340mb HD. Should I just leave it as is, or is it worth upgrading? It sounds to me like you repartitioned the drive accidentally, or did /label/creat/all, or did a wr-cmp test in the wrong part of the disk. You can boot fx from your installation media. From the PROM monitor, try (assuming the tape is at ID #7, for the sake of illustration): tpsc(0,7)fx.IP6 -x Faster graphics (a number of different options, although not all may still be available), more RAM (up to 32 MB officially, 64 unofficially), zbuffer, upgrade to 4D/35 (basicly same cpu and system architecture as r3k Indigo). Probably about $10K US to go up to the fastest graphics and the 4D/35, maybe even a bit more if you want to go to Elan, which the 35 supports, but the 20 does not). (44) - Maximum Memory on a 4D/25 --------------------------------------------------------------------------- I have a 4D/25 with 32 MB of RAM and understood that it was pretty much filled to capacity. Unofficially, how can I upgrade it to 64MB? Buy 4 MB SIMMs from one of the 3rd party vendors that knows SGI. The reason it isn't supported officially is that some DRAM initializes to all 1's, and some to all 0's, and the released PROM touches some memory (with 4 MB SIMMs only) before clearing it, and so gets a parity error if you use the "wrong" type. I believe the SIMMs with the Toshiba DRAMs worked, but I won't swear to it. (45) - Bru and M/O drives --------------------------------------------------------------------------- Don't know about flopticals, but bru works well with magneto-optical cartridges - very fast. When it hits the end of the media (290 Mbyte per side) it gives an error message and asks you to insert the next volume (i.e. turn the cartridge over) and then continues with the second part of the archive on the second volume. (46) - VME Transfer Problems --------------------------------------------------------------------------- Help! I have a 3rd party VME board which acts as a bus master doing block transfers to and from SGI main memory. The board worked fine when plugged into a POWER SERIES 4D/340 system. We upgraded our 4D/340 to a Challenge L and now the board crashes the Challenge. I've talked to several engeniers around here (here is Brookhaven National Labratory) and they all tell me ("VME is VME and your borad should work in any VME bus which claims to be a standard VME bus") The board does not crash the Challenge on single word transfers, only block transfers. To be more specific, If the block transfer involves more than 10 32 bit word tranfers, it crashes the system. If the block transfer is less than or equal to 10 32 bit word transfers, The Challenge does not crash. Could it be that SGI as come up with a 'higher standard' in VME bus for there Challange machine and that my board adheres to a 'lower standard?' My question is, has anyone out there had similar problems with their 3rd party VME boards plugged into the Challange L? Is there any advice that I can get from SGI about how to narrow down the problem so that I can point my finger at either the Challange or 3rd party board? One thing to note, this 3rd party board knows nothing about the 64bit VME standard. If you try to do 64bit tranfers to and from the board, this will crash the Challange. (But this should be of no concequence since I believe that would be able to stick a 32bit VME board into a 64bit VME bus. Right?) --- 1 --- Here at Toshiba we found a problem where an Internally designed VME board caused the SGI V35M DMA state machine to lock up when a Bus request resulted in a null operation, IE it released the bus right after getting bus grant. This state is easy to see by (I think) watching bus grant on the back plane, it will cycle endlessly with no other activity on the bus. --- 2 --- I'm following up to my posting of the Challenge crashing with my 3rd party VME board. It turns out that the SGI Challenge was at fault. Our maintance man suggested replacing all our boards (The CPU board, the IO4 board and the MEMORY board) with boards at the latest revision level. When we did this big swap, the crashing problem with our 3rd party VME board went away. I don't know what revision levels our boards were at that caused this crash, or what revision the curent boards are at, but what I does that our Challenge was delivered to us in late June of '93 and we just made the board swap this Wensday, Oct 13. --- 3 --- There is a known bug in the V35/V35M PIC1b arbiter that can cause graphics crashes during VME transfer. We are working on the resolution to this, but it looks as though we may have to add the VMAX card as a work-around. (47) - Pio_bcopyin and pio_bcopyout arguments --------------------------------------------------------------------------- To anyone on the internet! Do you have the parameters which are given to the subroutine pio_bcopy(). I have the Device Driver Programming manual which describes this routine, but it does not give me any detail on the parameters which are given to it. If you know, I'd be grateful if you would let me know what they are. See sys/pio.h. There is no pio_bcopy. There is a pio_bcopyin and pio_bcopyout. The 3 int args are size, itmsz, and flag. itmsz is 1,2,4, or 8, and is the size in bytes of each object to be copied (and determines whether the copy is a byte (8 bit), 16 bit, 32 bit, or 64 bit copy). size is the number of *bytes* (not number of objects) to copy, and must be a multiple of itmsz. flag is PIOMAP_* from pio.h I'm not sure, but it looks like this might one place where a relatively late change didn't make it into the driver guide, so the arguments are different in the documentation. (48) - DMA Rates on EISA & GIO --------------------------------------------------------------------------- I'm trying to find a system that can copy data from memory to it's i/o bus as fast as possible. I know that a SPARC IPX can copy to it's SBUS at about 16megabyte/sec without using DMA and since there are only lousy SBUS DMA controllers available I think this is all we can expect out of an SBUS box. Does anyone know any different? How about SGI? How fast can it move data to it's EISA bus (for indy or the indigo)? Are there EISA cards that can DMA data out faster than the CPU can copy it out there? No EISA on Indy. But EISA rates on Indigo2 (Indy's big brother) are right up near the max, if you are doing 32 bit transfers. I think 30 MB/sec if the gio bus runs at 33, and about 23 if it is running at 25 (as it does with Extreme graphics). GIO data rates can hit about 70% of theoretical, which means abyout 150 MB/sec on gio64, and about 75 on gio32. This is with DMA of course. PIO is a *lot* slower. (49) - SGI Periodic Table --------------------------------------------------------------------------- You may acquire table of SGI products /sgi/93.13.7_Periodic_Table.ps.Z via anonymous ftp from sgi.com (50) - Quick Ring for Indy? --------------------------------------------------------------------------- Has anyone heard of Quick-Ring being offered for the Indy? Quick-Ring is a multimedia communication network developed by Apple and National. It has just been announced (by National), I think; I hadn't heard anything was shipping yet. I haven't heard any discussion at all about ever doing it on SGI platforms. (51) - Reading audio from CD-ROM drive into aiff file --------------------------------------------------------------------------- Can anyone tell me where to get a program (pref anonymous ftp) that will allow me to read audio CD's on the SGI's CD-ROM and sample it into an aiff type file ? I wanted to read the samples directly into the file without conversion to analog if possible. If you are running the IRIX OS version 4.0.5F or later, you will find that you have the application "cdman" (/usr/sbin/cdman). It lets you play audio CD's and also sample them into aifc files which are pretty much the same as aiff files. If you really want aiff files you can convert the aifc file using soundfiler or sfconvert. (52) - Determining current video scan rate --------------------------------------------------------------------------- Looking through the last Pipeline, I was wondering if we had our video systems set to the 'best' vertical rate. I noticed that, while the default for the SGI's is listed as 60Hz, our monitors (19" Mitsubishi) can handle up to 130Hz. The setmon command may be used to change the rate, but short of writing a GL program, there seems to be no way to find the *current* setting. Does anyone have a program to verify the current mode? Also, and I suspect this would be so, wouldn't a 72Hz vertical rate on my hardware be better (less flicker under florescent lights)? Any comments appreciated. --- 1 --- Unless you are using *extremely* expensive monitors, I'd be astounded to hear that they could handle 130HZ non-interlaced. | Does anyone have a program to verify the current mode? Also, and | I suspect this would be so, wouldn't a 72Hz vertical rate on my | hardware be better (less flicker under florescent lights)? | Any comments appreciated. It might; depends on whether your graphics support it. XS does. There were also some monitors that didn't look too great at 72, as I recall. The 'default' they were referring to, was for monitors without the special cables that allow the system to figure out the monitor type, if I'm not mistaken --- 2 --- Try 'osview -i1'. The value displayed in the 'Graphics,gintr' field is approximately the vertical refresh rate. (53) - Using Vigra MMI-210 in a 4D/320S --------------------------------------------------------------------------- I'm evaluating a MMI-210 for an SGI 320S. The board is in and I can access on board memory from the host but I can't seem to make the interrupt stuff work. I have used the mmi-210 on SGI systems. I have not tried interrupts, however. You may want to check obvious things, however. For instance make sure that vme jumpers are in place for every slot skipped if the board is not in the leftmost available vme slot. I suggest contacting Vigra (619)597-7080 if you continue to have difficulties. (54) - Software upgrade required for R4400? --------------------------------------------------------------------------- recently ordered a R4400 upgrade for a Silicon Graphics Crimson Elan workstation. Is IRIX 4.0.5 compatible with the R4400? Will I have to switch to IRIX 5.0.1? I believe you will need a new one called 4.0.5J. Your service office should be able to provide it to you when needed (or it will come with the upgrade). (55) - FDDI in Indigo2 --------------------------------------------------------------------------- We just received an FDDI card for our Indigo2. The instruction say to move the Extreme cardset up one slot, and install the FDDI card in the bottom GIO slot. When we do this, we lose our graphics (so far, the hotline has been no help). Has anyone been able to make this work? If we do get it to work, can we install a Galileo card in the same system? --- 1 --- Sounds like you have a very early demo unit, and/or very early alpha software. If so, you'll have to get it upgraded. | Has anyone been able to make this work? Ifg we do get it to work, can | we install a Galileo card in the same system? Obviously it works, or we wouldn't have shipped it... We may be somewhat careless at times, but not *that* careless. --- 2 --- Pre-production Extreme graphics board sets only worked in the bottom slot. These boards were not supposed to be shipped to any customers. It sounds like maybe you have one of these. You should contact your local support person ASAP. >Has anyone been able to make this work? Ifg we do get it to work, can >we install a Galileo card in the same system? If you have FDDI and Extreme in the same machine, then there is no room for Galileo. Sorry. This is a sore point among many engineers here... There are ways of getting FDDI and video in an Indigo2 while sacrificing some graphics performance.. You should talk to your local sales person as I'm not sure what's been announced and what's shipping. (56) - 1024x768 support with Elan for projector --------------------------------------------------------------------------- We have an Indigo R4K Elan system (4.0.5f) which we would like to use with a VGA Barco projector. On reading the Sept/Oct PIPELINE, they indicate that Elan's will support 1024x768 graphics by using "setmon IRIS3K". When I try this, I get something like, "format unsupported". I "borrowed" a copy of setmon from 4.0.5h, including the ucode files, and tried it again. Still no luck. What do I have to do to make the Pipeline article right? --- 1 --- > they indicate that Elan's will support 1024x768 graphics /usr/gfx/setmon iris3k works on an Elan here under 5.1. I don't know about 4.x.x. > I "borrowed" a copy of setmon from 4.0.5h, DON'T DO THIS. You cannot mix-and-match microcode files between releases of the operating system. (The kernel and other bits of the graphics software are intimately tied to the VOF files). --- 2 --- >/usr/gfx/setmon iris3k works on an Elan here under 5.1. >I don't know about 4.x.x. When will this be available to the general public. I'm having the same problems. I need to get the IRIS3K and/or the 30HZ mode working on my Indigo. The ucode files for these modes were not included in the general distribution of the op-sys, but everyone I've talked to at SGI thinks that they are, and can't understand why this doesn't work on my machine. It seems like all the machines at SGI have workiing versions of these modes, but not the machines in the field. (57) - Reading data from DAT with a program --------------------------------------------------------------------------- I'm looking for pointers to information that will tell me how to read data from an Indigo internal DAT tape drive under program control. I'm an engineer working on a DSP/data analysis project. The lab digitizes their observations on DAT tape and my job is to write a system to reduce and analyze it. The current method is to play back the tape on a high-fidelity audio recorder, digitize the data on a PC, ftp it to a Sun, resample it to 48K (because the PC sampling board has a screwball clock), and then run the DSP programs (which must run on the Sun because they're far too big to run under MSDOS). Having read this far, you can imagine my joy at discovering an under-used Indigo with a built-in DAT tape and a large hard-disk. Visions of a seamlessly integrated all-in-one, from-tape-to-report, no-additional-noise-from-redigitizing application danced through my head --- only to be cruelly dashed when I discovered that there was absolutely no documentation on how to control the tape-drive or read data under program control. My requirements are simple. I *must* control the tape drive because I haven't (and will never have) enough disk to read and process an entire DAT tape all at once. In practice, I face two situations: (1) If I'm very lucky (and the lab staff observed the experiment and noted the time of *all* of the "interesting" events), all I have to do is spool the tape to a few selected spots, read the data from each event into an appropriate buffer, and process it. (2) If I'm not lucky, I need to read the entire tape buffer-by-buffer, look for events in software, and then process them when they are found. (This is the normal case.) In either case, I will have to read (both channels), fast-forward, and rewind the tape and read the time-code in order either to find the events (if I have approximate times) or determine the time (if I find an un-recognized event). This can't be the first time this has been done and I can't be the only engineer who's had trouble finding the documentation. I'd love a pointer to documentation, example code, FAQ, or (dare I hope?) the name or ftp location of some archive containing a package that already does exactly this sort of thing. (Right now, I'd settle for the right subject for a man page. I've tried all the ones I can think of.) I don't care whether the package is public-domain or commercial (my project has a budget) as long as it can be customized to meet my needs. (But my experience is that PD is better in this regard.) Suggestions, comments, and criticisms are welcome. Please feel free to flame at me to RTFM, but please also tell me where in TFM to R. (Please also tell me which FM it is, so I can make sure we have it or order it if we don't.) Try 'man datframe dtintro' as a starting point. Or just use datman and record to file function to get an AIFC file with the data. apropos 'dat' does a good job of finding these (assuming you have installed the digital media libraries). | My requirements are simple. I *must* control the tape drive because I | haven't (and will never have) enough disk to read and process an | entire DAT tape all at once. datman will do still do the job, as long as you have some kind of timecode; you can select the timecode to seek to, and you can stop the 'record to file' manually. Not as elegant as doing it under program control, but a lot simpler to get started ;) | Suggestions, comments, and criticisms are welcome. Please feel free | to flame at me to RTFM, but please also tell me where in TFM to R. | (Please also tell me which FM it is, so I can make sure we have it or | order it if we don't.) Assuming you have 405F or the Indigo Patch, you want the dmdev product (seperate from the IDO). In 5.1, I think it is part of IDO, but I'm not positive. (58) - Replacement Indigo Keyboard? --------------------------------------------------------------------------- Can anyone suggest a source for a replacement Indigo keyboard and mouse? I am trying to find something cheaper than the spare parts SGI sells (total for the two is approx. $500 from SGI). Can I use a PC or Mac keyboard & mouse? If someone can send me specs and pinouts, I'll hack together my own cable... --- 1 --- Nope. Only Indigo2 and Indy can use PC keyboards. man serial keyboard mouse gives pinouts, etc. Good luck... --- 2 --- There's a surplus place in the bay area which had a pile of SG keyboards last time I was in CA-- I think they wanted about $50. for them. Sorry I don't remember the name and I'm pretty far from there at the moment, but maybe some kind reader can fill in the blanks. The place is just across the street from the Sunnyvale Fry's. --- 3 --- Weird Stuff; several outlets around the SF Bay Area. stock varies tremendously with time, but almost always interesting... Most of it isn't guaranteed to work (there are significant exceptions), and is sold "as is". (59) - Can't find tape drive on 4D/35 --------------------------------------------------------------------------- we have a problem with our SGI QIC 150 tape drive in our SGI 4D/35 TG running IRIX 4.04. After we had reinstalled our tape drive back in the system (we have used it in another machine for a while). All seems to be alright, hinv shows the device : Tape drive: unit 2 on SCSI controller 0: QIC 150 and the confidence test was also alright. But if I use for example comand tar tv, the following error message appears : tar: /dev/tape: No such device Could somebody help me, because we are confused and do not know what we can do ? Please mail me your informations. If tar is not given a specific tape device name it uses /dev/tape which is a link to some specific tape device. To figure out which tape device the system thinks is '/dev/tape', do the following: ls -li /dev/tape You'll get something like this (this is from my system): 725 crw-rw-rw- 1 root sys 144,704 Oct 8 16:44 /dev/tape --- Pay attention to the minor device number --^ , then type ls -li /dev/mt/tps* | grep 704 What I got was: 727 crw-rw-rw- 1 root sys 144,704 Oct 8 16:06 /dev/mt/tps1d6 420 crw-rw-rw- 1 root sys 144,704 Oct 4 16:00 /dev/mt/tps1d6s Which shows that SCSI ID 6 on the second SCSI bus (I'm running an Indigo2) is the device linked to /dev/tape. My guess is that one of the following things is happening: /dev/tape is linked to some device that doesn't exist (for instance if the SCSI ID was changed when used on the other system). If this is the case, linking /dev/tape to the proper device in /dev/mt would solve the problem. You've rebooted and reconfigured the system since you removed the tape drive. This might have caused the system to remove the tape devices. To remedy this, do "MAKEDEV tape" as root. Of course, if you want to check out the drive without doing any of that use the 'f' option of tar: tar tvf /dev/mt/tps0d2 That ought to work. (60) - Will 525 MB tapes work in QIC 150 drives? --------------------------------------------------------------------------- I was wondering if it was possible to use a 525 MB tape in our QIC 150 tape drive. Has anyone tried that? Will I be able to use it all instead of only 150 MB? No, it won't work. Different tape formulation. If capacity is what you need, the DC6250 tapes are just longer versions of the 6150's, and will get you near 250 MB, rather than 150. The newer QIC1000 drives can read and write the 525 and 325, as well as all the QIC-150 media, and the QIC1000 media. (61) - Second SCSI bus for Indigo? --------------------------------------------------------------------------- I was wondering if anyone (Hello, Dave :-) ) knew if there was a second plug-in SCSI card for the GIO bus that would work on an Indigo R4000? If so, does the generic SCSI driver work with it? I need to isolate a SCSI device on its own bus, because of some slightly non-standard behavior, and it will need its own driver. It's not a hard drive or storage device, it's actually a piece of data acquisition hardware. If you know of a card, any guess on pricing? Thanks, and I will contact SGI Express or sales rep as well, but they wouldn't know about the generic SCSI driver :) Nothing available. There has been some work on prototypes, but I don't know if it will ever be made into a product. devscsi did work on the prototypes, and would presumably work on anything made into a product. If it were done, it would probably be about the same price as the GIO ethernet card for Indigo (I don't know what the price on that is). (62) - Audio programming on Indigo2 (applies to Indigo and Indy as well) --------------------------------------------------------------------------- I would like to do some programming of the audio-interface of a SGI (indigo^2) in C. Therefore I would need any introduction on how to use the audio-device, the audio input and output ports, the DSP, etc... Does anyone of you know of any books, papers, etc. covering those topics? Ask your salesman for the Digital Media Developer's CDROM 1.2, for a myriad of audio libraries, example source code and documentation. (63) - Audio programming - part 2 --------------------------------------------------------------------------- We are currently working on a project that involves real-time signal processing on sound. As the SGI Indy both has a fast processor and high quality sound in/out, we would like to utilize this, and use it as a platform for our application. The only example programs I could find here at the University's Indies were in /usr/people/4Dgifts/devaudio. These use the /dev/audio device directly, but there must be some more support for audio playback, like channels ? Or do I have to multiplex and scale manaully, if I want to play several sounds at different volumes simultanously ? I cannot use the high-level audio tools, since we have to do sampling, processing and playback in real time. The manual pages refers to some other source code which is not installed here, like audio/playaifc.c. I would be grateful if somebody could send me some of those, as well as the part of manual section that deals with audio subroutines (not commands), which we don't have. I have compared the /usr/include/sys/audio.h file on Indigo and Indy, and the one on Indigo states many more calls and options. Does this mean that source code using audio for Indigo is not compatible with Indy ? To get started, it would be convenient to have an example program that samples from line in, and outputs to line out. If anybody has something like this, please send it to me. I would also be grateful for any other spesifications or tips on how to use the low level support of the audio system on Indy. You need to get the Audio Library (AL) which is part of the Digital Media Developers Option. You will also need the Irix Developers Option if you do not have it already. (64) - Power Connections for SGI systems --------------------------------------------------------------------------- Could someone let me know the type of power (amps) and socket style (twist-lock, etc.) connections required for the following machines. In other words, what kind of "plug" do I need to make these things work. 4D 420 Single Tower 4D 340 Twin Tower 4D 210 Twin Tower Onyx/2 Deskside Onyx/2 Rack (terminator chassis) --- 1 --- 4D 420 Single Tower 20 Amp Recepticle looks like -| | o and it's name is "NEMA 5-20R" but the plug is called a NEMA 5-20P 4D 340 Twin Tower "same as above" 4D 210 Twin Tower "same as above" Onyx/2 Deskside depends either 20 amp 120 volt like above in minimal configurations. or a 220 volt recepticle like this | - o but it real name is "NAME 6-20R and the plug is called NAME 6-20P Onyx/2 Rack (terminator chassis) OHH, Well the single phase receptical is a HUB-330R6W which looks kinda like the plug your boat might have if you paid more than $30,000 for it. and the plug's name is IEC 309,2-P,3-W,30A,250V but we call him harvey for short. and the three phase plug is called a IEC 309,3-P,4-W,30A,250V and plugs into a HUB-430R9W which looks like the plug on your boat if your boat had an electric crane which picked up cars or something. (65) - Maxtor 8760E drive on 4D/240S --------------------------------------------------------------------------- We have an SGI 4D/240S with an ESDI controller and a single drive. We have recently aquired several Maxtor 8760E drives with their own power supplies sold by Aviv which were originally on a VAXstation. We would like to add these drives to our SGI, however we are having a problem. We first removed the terminator from the drive which was already installed in the SGI, and left the terminator in the single Maxtor that we were adding as a test. The preinstalled drive was set to ID 0 and the new one to ID 1. We then started fx in the extended mode, chose the ESDI controller, drive number 1, and identified it as a Maxtor-8760E (number 30 on our version of fx). We then attempted to format the disk using the 'auto' option, and the format stage seemed to work, however, once it began excercising the disk, it generated errors such as this: ips0d1s10: sector not found (code 29) chs/4/2/40...about to do first retry. ips0d1s10: sector not found (code 29) chs/4/2/40...about to do second retry. ips0d1s10: sector not found (code 29) chs/4/2/40...about to do third retry. fx/auto/complete I/O error - write error at block 4/2/40 (3348) adding bad block 4/2/0 this continued until fx encountered enough errors to ask if it should continue. When we tried excercising it sequentially, it seemed to find that there was at least one bad sector in each track, thus adding it to the bad block list. We are at a loss as what to do next, and were wondering if anyone had experience with these types of drives, or similar errors in 'fx'. Incidentally, the one possibility that we thought of is an error in terms of selectable options through jumpers on the drive. It is set to 'hard sector mode' with 'ESDI programmable sector size' enabled. I'm not sure if changing this is the answer, and I grow tired of random changes trying to get this to work! This takes me back about 4 years. Talk about nostalgia! The Maxtor drive never did work very well on the ESDI controller. About the only thing I can suggest it to choose the 'other' drive parameters and play with gap sizes -- not very useful information, I know. Unfortunately, the drive was always quite persnickety with this controller, which is why we never sold it. We did supply the parameters for it, though, in case others wanted to try to use it. The 780MB drives we shipped were the Hitachi DK515-78 and Seagate (or CDC) Wren 6. (66) - Panic crashes --------------------------------------------------------------------------- since 11 month we have an Crimson Reality Engine. There are two harddisks installed inside. One harddisk and a cdrom are connected to first of the two external scsi-ports. A dat-tape-drive is connected to the second one. The cables of the first port are around 2 Meters, the second around 1 Meters. I think there are no to long: Since 2 Weeks the system crashes with the following output: PANIC : IRIX killed due to MP Bus Timeout PC: 0x80009F4A4 ep: 0x80111DC0 Physical Address 0x17000700 DOUBLE PANIC: .... Any tips or suggestions ? Since I haven't seen any other replies... Use dbx or dis on the kernel to check where that PC is (what kernel routine). If it happens repeatedly, is it always at the same PC? Sounds like something is making a bad access. Also, what changed in the hardware or software about the time you started seeing the problem, if anything? (67) - Swap space or RAM? --------------------------------------------------------------------------- I have a few questions about using swap space instead of RAM. The system I am using is an Indigo^2 with 32Mb of ram and 1.5Gb of hard drive space. I will be upgrading to 64Mb shortly, but need to do some large memory intesive calculations now. How does using swap effect the lifetime of the hard drive? Is 1Mb of swap equivalent to 1Mb of ram. I know the swap runs slower, but how much slower? The programs I will need to run will take aproximately 6 hours each to run, but I will eventually need to run a few that may take a couple of weeks. Should I go ahead and use the swap or wait until I upgrade to the 64Mb of ram? Disk speed is about 2 orders of magnitude slower than memory. If you have the time to wait... You really don't want to run programs that page heavily for long periods, given any choice at all. It certainly won't hurt the disk, but it is rather hard on your patience! The disk is, after all, designed to be used ;) (68) - Help with Exabyte 8505 tape drive --------------------------------------------------------------------------- I need some help with an 8505 Exabyte tape drive. I need drivers. I have it on my system but it will not read any of my old 8200 tapes!! --- 1 --- No, you do not need drivers. The necessary drivers are already in the kernel code libraries and most likely are already in your kernel. What you may be missing are character special device files. You want a set that allows you to specify to the tape drivers in the kernel that you want to use your tape drive in low-density (a.k.a. 8200 mode). And, you should also have the means at hand to make those as well. Do you have a MAKEDEV shell script in /dev? If so, /dev/MAKEDEV tps, should create the necessary character special device files for you if you have the device properly installed on your system before you execute the MAKEDEV shell script. Character special device files are not drivers. Whenever you install a new device on your system, it is most likely a good idea to run /dev/MAKEDEV without arguments. --- 2 --- |No, you do not need drivers. Well, not exactly. For reading, any old generic entry from tpsc should do the trick, since the 8505 will sense the tape density (i.e. the type of 8200/8500/8505/8500c drive format) For writing, the mode select for the desired density will be required unless the default is OK. If this is the case, then a simple mod to tpsc will be required. Then a reconfig to make all this complete. |The necessary drivers are already in the |kernel code libraries and most likely are already in your kernel. Again, not likely. I think the tpsc only includes 8200 and 8500, if I remember correctly. | |What you may be missing are character special device files. You want |a set that allows you to specify to the tape drivers in the kernel |that you want to use your tape drive in low-density (a.k.a. 8200 mode). | Here's the actual scoop. It won't be density on read (the Exabyte ignores and mode_select density stuff on read), but the swap/no swap is most likely what is needed. For example, maybe try dd, then conv=swab to see if that is the problem. Otherwise, make sure that there is an appropriate entry in tpsc, and that the special file has the (minor) bit set for the desired swap/no swap. |And, you should also have the means at hand to make those as well. | |Do you have a MAKEDEV shell script in /dev? If so, /dev/MAKEDEV tps, |should create the necessary character special device files for you if |you have the device properly installed on your system before you |execute the MAKEDEV shell script. And there's the rub. If hinv responds with Device: unknown then the MAKEDEV script will not create the appropriate special files. Once again, depending on the way that tpsc was modified, then an appropriate modification to MAKEDEV will be required. Otherwise, just do a mknod for the necessary /dev/rmt specials. | |Character special device files are not drivers. | |Whenever you install a new device on your system, it is most likely a |good idea to run /dev/MAKEDEV without arguments. hope these few ideas help clarify... I have the 8505 running on four Indigos here, and have the mods for tpsc and MAKEDEV, as well as a program I wrote to querry the drive to determine compression performance. If anyone is interested, I'd be happy to share (a number of folks have asked for this stuff, and it is working for them) (69) - Indy Third Party Drive Problems --------------------------------------------------------------------------- We have recently purchased a number of INDY's (PC's and SC's) and are having a lot of problems with various third party peripherals. The problems seem to arise on systems with say one fast SCSI drive and one standard SCSI drive. As an example I currently have a PC running IRIX 5.1.1 with a Seagate 450MB fast SCSI drive internal (device 1) and an external Quantum 207MB standard SCSI drive (device 3). At boottime a diagnostic window appears and complains about a lack of response from SCSI id 4 and does a SCSI Bus Reset. The system continues to boot. Once I have logged in I was under the assumption that I would see and unnamed disk icon on the desktop - there isn't one. I run "fx" and tell it that I am interested in SCSI id 3 and it gets an I/O error and the SCSI bus gets reset. I have used a standard SCSI drive on an SC already (no internal drive) so I assume that standard SCSI drives are fine. Is it simply the combination of fast and standard SCSI drives that causes problems or is there more to it than that? --- 1 --- | from SCSI id 4 and does a SCSI Bus Reset. The system continues to | boot. This almost certainly means that the Quantum drive is botching sync negotiations. Try editing /var/sysgen/master.d/wd93 to disable sync on SCSI ID #3. The irix 5.1.x (for some x > 1) should report this particular error a bit better. | I run "fx" and tell it that I am interested in SCSI id 3 and it | gets an I/O error and the SCSI bus gets reset. Probably sync again. | I have used a standard SCSI drive on an SC already (no internal | drive) so I assume that standard SCSI drives are fine. Almost certainly has nothing to do with PC vs SC. Also check to be sure that you have active termination (no terminator in the drive), and *good* cables, and that total cable length is < 3 meters. --- 2 --- >and *good* cables, and that total cable length is < 3 meters. I found this in "relnotes impr_desktop 3", and have not seen it anywhere else. Seems like kind of a strange place for such an important bit of information for us SCSI device types. Anyway, in the second bullet item, it reads: o On Indy systems, there is currently a 2m (6 foot) maximum cable length limit on SCSI devices instead of the normal 6m (18 foot) maximum cable length. If you experience "SCSI Bus Reset" problems, try a shorter SCSI cable. --- 3 --- | in the second bullet item, it reads: It is there for the SGI SCSI printer (which we OEM'ed; I think it is now being supported by Genicom directlry). It should also be in the Indy owner's guide. (70) - R2000A/R3000 - What does this mean? --------------------------------------------------------------------------- When I run "hinv" on our 4D/340VGX Power Series machine, it says this about the processors: 4 33 MHZ IP7 Processors FPU: MIPS R2010A/R3010 VLSI Floating Point Chip Revision: 3.0 CPU: MIPS R2000A/R3000 Processor Chip Revision: 2.0 What does R2000A/R3000 mean? How can I tell whether it's R2000A or R3000? >What does R2000A/R3000 mean? It means that the processor uses the R2000A/R3000 instruction set. >How can I tell whether it's R2000A or R3000? From looking at the hinv output it could be ambiguous, unless you just "know" these things. You could just look at the chip itself, but that might void various support warranties regarding user serviceable parts. This is an approx MIPS family breakdown based on cpu board type numbers: R2000 - IP4 R3000 - IP5,7,9,12 R4000 - IP17,19,20,22 (71) - Heat problems with Seagate Barracuda in an R4000 Indigo? --------------------------------------------------------------------------- I'm planning to install a Seagate Baracuda 2 disk drive in an R4000 indigo and I've heard rumours of possible heat problems - can anyone clarify this? The Indigo in question has an elan card and a single 400Mb (approx) system disk drive, the other two 3 1/2" slots are currently vacant - am I likely to have problems? There were concerns that there might be heat problems (not enough air flow), but so far, that appears to not be the case for Indigo2 in some preliminary work. I don't know if that drive will be officially qualified or not. I don't know if any qualification work is being done on Indigo or not. Certainly airflow is lower in Indigo around the drives. I'd keep a close eye (finger) on the drive temperature. (72) - Optical Disk Drive suggestions? --------------------------------------------------------------------------- Our lab is thinking of getting an optical disk drive. We would like to get one with a large-ish capacity (around 2Gb) if possible. So, I guess I'm begging for any advice on price and quality for such a disk drive. We are using a fast Hewlett-Packard mechanism in a third party packaged drive as an external on an Indigo R4K, and are happy with it. The 5.5 inch media does 590 Mbyte with 512 byte/sectors - necessary for SGI machines (don't get the alternative 1024 byte/sector media). This is a 'standard' format that works in many drives. You have 290 Mbytes on each side of the disk. There are higher (less standard) densities eg Tahiti,and I have recently seen other 1.2 Gbyte media 5.5 inch drives. However, check the price of the media. The standard 590 Mbyte disks cost much less than $100, while double density media can cost 3-4 times as much. You will want more disks than you imagine, since it is so easy to use it for various backups, copies etc. We even use it over ethernet for backups of our Macs, and already have 20 disks - 12 Gbyte! Make sure you get one of the much faster split-optic head drives. (73) - Moving a drive from one machine to another --------------------------------------------------------------------------- I will be getting more diskspace, and I will want to move an external scsi drive from one machine to another. I want to keep all the data that is on this external drive. Question: Can I just move it to another machine and all the data will be there. Or do I need (I will do it anyway, but...) to do a backup of it before I remove it from the current machine. My suspicion is that I must do a backup of it then reinstall it on the disk after it gets added to the new machine. Is this true? --- 1 --- Assuming it is from one SGI system to another, you should be able to just move it, but I'd certainly be paranoid and back it up first, if you care about any of the data (you might have a head crash, or might make a mistake while doing the setup on the second machine). Also, if it is the system disk, and the machines are different types, or different graphics, you might have to reinstall parts of eoe1 and eoe2 with 'set neweroverride' in inst. --- 2 --- If the machine being moved to is of the same type of system, running the same O/S (more or less), you should be able to plug the drive and it should work. (You may have to dither with the SCSI address and /etc/fstab and so on.) If you are moving drives between non-compatable systems (say a Sun to a SGI), then yes, you will have to re-format the disk and start with fresh file systems -- SunOS has a different idea of what a hard disk looks like (system label, partitioning info, file system layout, format of the superblocks, etc.) from IRIX (or Ultrix, etc.). (74) - IO4 Bus arbitration question --------------------------------------------------------------------------- I was interested in the IO4 bus arbitration logic. Besides the general description, does SCSI controler 0 have and advantage over SCSI controler 1 ?? Not that I know of, in practice. One of the challenge folks may be able to reply with more assurance. (75) - Disk drive problem with Indigo --------------------------------------------------------------------------- Recently I installed a DEC DSP3105 in an Indigo R3000. Everything seemed to be working fine, until today when I tried to use the internal 3.5 inch floppy... msdosd gave me errors when I started it. I used hinv to see what it had to say: 1 33 MHZ IP12 Processor FPU: MIPS R2010A/R3010 VLSI Floating Point Chip Revision: 4.0 CPU: MIPS R2000A/R3000 Processor Chip Revision: 3.0 On-board serial ports: 2 Data cache size: 32 Kbytes Instruction cache size: 32 Kbytes Main memory size: 24 Mbytes Integral Ethernet: ec0, version 0 Disk drive: unit 7 on SCSI controller 0 Disk drive: unit 6 on SCSI controller 0 Disk drive: unit 5 on SCSI controller 0 Disk drive: unit 4 on SCSI controller 0 Disk drive: unit 3 on SCSI controller 0 Disk drive: unit 2 on SCSI controller 0 Disk drive: unit 1 on SCSI controller 0 Integral SCSI controller 0: Version WD33C93A, revision 9 Iris Audio Processor: revision 3 Graphics board: LG1 Yikes!!! I only have 1 disk, at unit 1, and one floppy at unit 3. Why all these other phantom disks? I wouldn't mind if they were REAL, but this is kind of annoying! Could anyone shed some light on this? This symptom indicates that the device is addressed as 0. When a disk is addressed at zero, it can sometimes be seen at every address, because when the host adapter asserts its ID bit during selection, the disk thinks it's being selected too. (76) - Print problems with LaserWriter Pro --------------------------------------------------------------------------- Don't point me at "man serial". I've been there. My problem is a little more specific. I have a LaserWriter Pro 600 with a serial DB-9 connector running to an R3000 Indigo (with a DIN-8 connector). I have been able to access the printer using the ttyd* but I want to get at least XON/XOFF control so ttym* is needed. With the cable that I have, I can talk directly to the printer using ttym* and kermit but, when I use ttym* in the printcap, files just disappear and the printer never starts processing (as indicated by the flashing light). If you have managed this, can you describe in detail your cabling? Hardware handshaking using ttyf* would be even better but I don't think the printer will talk RTS/CTS. My cable looks like this: DIN-8 DB-9 (according to LW manual) DTR 1 ----------------------------- 1 DCD CTS 2 8 CTS TxD 3 ----------------------------- 2 RxD SGnd 4 --------------+-------------- 5 SGnd RxD 5 ------------- | ------------- 3 TxD RTS 6 | 7 RTS DCD 7 ------------- | ------------- 4 DTR SGnd 8 --------------+ 6 DSR 9 Ring I fear that I need to drag some of the other pins high/low in order to avoid floating lines but I don't know precisely what to do. NOTE: I have set the configuration on the printer to use XON/XOFF, 8None, at 9600 (setting 0), checking it through a Mac connected to the LocalTalk port. If you want XON/XOFF, then ttyd# is just fine. You almost certainly don't want the modem signals (unless you tend to power your printer off a lot), so it is either ttyd or ttyf. | the printer never starts processing (as indicated by the flashing | light). That sounds pretty weird, as it indicates that the job is either being scrapped, or that the spooler thinks it printed it OK. Are your tty[mf]# devices owned by lp? Are there messages in ~lp/log? Your pinout below looks reasonable. (77) - NFS performance problems on 4D/35 --------------------------------------------------------------------------- We are experiencing some performance problems on our Model 35 NFS server. One of the symptoms is that there appears (osview, sysmeter et al) to be 4 - 10 times as many packets comming in as going out. A "sniffer" on the net seems to indicate that the SGI is actually processing each and every packet on the net. Can an ethernet interface get "stuck" in promiscuous mode? We're running IRIX 4.0.5. Another 2 SGI's on the same net (one also running the same release of IRIX) do not show this high number of input packets. | We are experiencing some performance problems on our Model 35 NFS | server. One of the symptoms is that there appears (osview, | sysmeter et al) to be 4 - 10 times as many packets comming in | as going out. Not unreasonable, for many things. Particularly if you have an app (or system) out there doing lots of broadcast or multicast packets. | A "sniffer" on the net seems to indicate that the SGI is actually | processing each and every packet on the net. Sounds like you have the somewhat bogus patch installed (posted here many months ago) that permanently puts the 4D/35 in promiscuous mode. I'd check your startup scripts. | Can an ethernet interface get "stuck" in promiscuous mode? Yes; it isn't stuck though, it is done deliberately (for snooping, or the like). (78) - Indigo Environmental Operating conditions --------------------------------------------------------------------------- While most people operate their computers in the comfort of a machine room or offices, we take them up flying !! Our intent is to use Indigo computers for airborne experiments (not allowed to tell you too much about them). This means they will be subject to pretty nasty vibrations, accelerations and temperature variations. Can anyone comment on the environmental envelope (accelerations, temperature extremes) within which Indigo computers are expected to operate properly? Silicon Graphics' technical reports don't specify anything about that (which is not entirely surprising :-)). --- 1 --- Actually, those things *are* spec'ed. I think they were in the owner's guide. This question has come up before, and vibration and temperature changes (rate of change, and endpoint temperature) for the disk are usually the biggest issue. If the cabin isn't presurized, you'll have even more problems. --- 2 --- We actually have put several SGI machines on VME boards for "embedded systems" applications; this might be better for your needs than strapping a purple box in with a seat belt. I'm pretty sure at least one Indigo variant is available. I don't have much information about these systems; you may want to check with your sales rep. (79) - Apple CD-ROM - Part 2 [see (37)] --------------------------------------------------------------------------- I'm presently a Mac and Iris 4D user. The Macs are used in my office and at home while the Irises are used in my lab. In the short term I need a CD ROM player at home and am considering the Apple CD 300. However, I may in mid or late '94 dump my home Mac in favor of an SGI Iris. Will the Apple CD 300 work on an Iris (including for software installation)? I've had many people ask, but only a few people try. They haven't been successful; evidently the firmware is rather Mac-centric, and therefore not terribly ANSI SCSI compliant. I suspect that Sony sells a more standard version of the drive, but I don't have the info on the model number, and I don't know if it would work on the Mac or not. (80) - Difference between R4000 in Indigo and R4000PC in Indy --------------------------------------------------------------------------- could somebody explain the difference between the R4000 found in an indigo 4k, the R4000PC in the PC Indy and the R4000SC in the SC Indy? --- 1 --- Originally, the R4000 had three variants: PC, SC, and MC which stand for Primary Cache, Secondary Cache, and Multiprocessor (Cache?) respectively. The PC chips are in a smaller cheaper package, while the SC and MC chips both come in the same package. I believe the MC parts didn't start working until a couple of revs on the silicon. I'm not sure if they sell separate SC and MC parts now. The R4000PC has 8K I + 8K D cache. Hence in the Indy, the R4000PC machine is quite a bit cheaper because it uses a less expensive processor as well as not having cache. The SC upgrade involves getting a new CPU. A plain R4000 is likely an R4000PC if it does not have a secondary cache. Otherwise it has to be an SC or MC part. Added into the fray is the R4400. This is available in at higher clock speed (75/150MHz as well as the original 50/100MHz) and has 16K I + 16K D cache. This part is still sold in both a PC and SC variant. I don't know if chip vendors sell a separate multiprocessor qualified MC version. Actually, how hard is it to come by R4400 150MHz parts? They seem to be a bit rare compared to what I'd expect. Those 200MHz parts better be coming soon with DEC flogging another 75MHz out of the 21064 and all :-) --- 2 --- The R4000 in the Indigo is an R4000 SC (secondary cache). Both it, and the Indy SC have 1 MB of secondary cache. The PC version has no secondary cache (nor the pins for it), and therefore has only the 8+8KB of primary cache (16+16 should it switch to the R4400 PC, which might happen at some point). The R4000SC also has 8+8 primary, and the R4400SC has 16+16 primary).